| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > перегрузка "operator new" и "malloc()" |
| Автор: andrew_121 8.6.2008, 17:52 | ||
| И снова Здравствуйте. Продолжаю тему по ускорению работы программы. И так... Со строковыми функциями вопрос решен.(http://forum.vingrad.ru/forum/topic-215618.html) Но актуален вопрос о выделении памяти. Есть мнение что, если перегрузить "new" и "malloc()", которые будут выделять память из предварительно выделеного массива, то затраты ресурсов существенно сократятся. Часть кода я вижу такой:
Вопросы: 1. Как в этой строке "char* buffer = (char*)malloc( N );" использовать стандартный malloc() ? 2. А в этой "char* str = strdup( "abcdef" );" перегруженый ? 3. Как реализовать учет памяти ? 4. Каким образом "free()" должен освобождать память. 5. Как бороться с фрагментацией памяти ? |
| Автор: jonie 8.6.2008, 18:32 |
| http://www.rsdn.ru/article/cpp/QuickHeap.xml вот это почитайте. |
| Автор: Lazin 8.6.2008, 20:54 | ||
я так понимаю, что программа уже написана, и ее нужно ускорить? если да, то нужно смотреть не на реализацию malloc и strcmp, а на используемые алгоритмы.. можно-ли изменить самые тяжелые алгоритмы так, что-бы сложность уменьшилась(вместо O(N*N)->O(log N) и тд), а то что делаешь ты, это тупиковый путь. Добавлено через 33 секунды попробуй, сэкономит кучу времени =) |
| Автор: andrew_121 8.6.2008, 21:35 |
| Lazin Спасибо...думаю... |
| Автор: bsa 9.6.2008, 16:09 |
| andrew_121, к вопросу о профайлерах... Был у нас программист. И сделал он классную вещь - идентификацию объектов по строковому ключу. Программа жутко тормозила... После прогона через профайлер выяснилось, что больше всего времени кушает алгоритм сравнения строк в std::map. Как ты думаешь, что я сделал? Ускорил операцию сравнения строк? Ничего подобного. Я посмотрел и выяснил, почему это происходит. А происходит это потому, что 60 раз в секунду обрабатывается порядка десятка супер объектов, каждый из которых обрабатывает порядка десятка объектов, определяя их в каждый конкретный момент путем поиска в 2-х вложеных картах (имя - <серия объектов>, имя - объект). Сделав так, что поиск происходил только на этапе создания супер объекта, я победил проблему. Заниматься operator new() нужно тогда и только тогда, когда профайлер показал, что они узкое место, а оптимизация очень нужна. Кстати, malloc() ты не перегрузишь. И вообще, зачем мешать в одной программе и malloc() и new? |
| Автор: MAKCim 9.6.2008, 17:18 |
glibc позволяет |
| Автор: andrew_121 9.6.2008, 17:26 | ||
| bsa: Спасибо. Да, я понял что, исправлять последствия кривого ума, не лучший выход. Вот, размышляю, над тем как правильней побороть сию проблему... Профайлер говорит что, бОльшая часть времени уходит на, соответственно:
Но я уже и так, заменил стандартные на макросы. Помогло, на 14%. Есть еще один, абсолютно правильный выход...но работы ооооо как много. Продолжаю размышлять.... |
| Автор: d06osipov 9.6.2008, 18:56 |
| У Александреску это описано подробно. И неплохую реализацию (с перегрузкой new и delete) содержит библиотека loki. |
| Автор: bsa 9.6.2008, 21:52 |
| andrew_121, думаю, стоит подумать о сокращении количества вызовов этих функций путем изменения алгоритма. Если невозможно изменить алгоритм, то стоит максимально ускорить эти функции (например, считывая за единицу времени не символ, а четыре (восемь, шестнадцать...) символа). Если не поможет, то только смена железа. |
| Автор: baldina 10.6.2008, 00:05 | ||||
не глянуть ли в сторону std::string? там хотя бы бесполезных поисков конца строки нет... Но это так, слезы: действительно на алгоритм посмотреть надо, может и не нужны там все эти strcpy и strdup ;) |
| Автор: andrew_121 10.6.2008, 01:35 |
| baldina: Прога писана не мной. А предидущим прогером. Прога жутко большая. Я заменил вызовы стандартных функций, макросами, помогло. Но радикально перепахивать код не охота... |
| Автор: bsa 10.6.2008, 13:35 |
| andrew_121, профайлер должен показать полный стек вызовов этих процедур. Найди наиболее часто встречающуюся ветку и ее переделай. |