И снова Здравствуйте.
Продолжаю тему по ускорению работы программы.
И так... Со строковыми функциями вопрос решен.(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. Как бороться с фрагментацией памяти ?

http://www.rsdn.ru/article/cpp/QuickHeap.xml

вот это почитайте.

Этот вопрос рассмотрен в книге Элджера по с++, "C++ for real proreammers" или что-то типа этого. Он там рассматривал эти вопросы выделения на нескольких десятков страниц. Так что rtfm.

А вообще есть такая штука - профайлер. Лучше его пользовать вместо такого гадания на гуще



Это сообщение отредактировал(а) Mayk - 8.6.2008, 18:45

я так понимаю, что программа уже написана, и ее нужно ускорить?
если да, то нужно смотреть не на реализацию malloc и strcmp, а на используемые алгоритмы.. можно-ли изменить самые тяжелые алгоритмы так, что-бы сложность уменьшилась(вместо O(N*N)->O(log N) и тд), а то что делаешь ты, это тупиковый путь.

Добавлено через 33 секунды

попробуй, сэкономит кучу времени =)

Lazin Спасибо...думаю...

andrew_121, к вопросу о профайлерах...
Был у нас программист. И сделал он классную вещь - идентификацию объектов по строковому ключу. Программа жутко тормозила... После прогона через профайлер выяснилось, что больше всего времени кушает алгоритм сравнения строк в std::map.
Как ты думаешь, что я сделал? Ускорил операцию сравнения строк? Ничего подобного. Я посмотрел и выяснил, почему это происходит. А происходит это потому, что 60 раз в секунду обрабатывается порядка десятка супер объектов, каждый из которых обрабатывает порядка десятка объектов, определяя их в каждый конкретный момент путем поиска в 2-х вложеных картах (имя - <серия объектов>, имя - объект). Сделав так, что поиск происходил только на этапе создания супер объекта, я победил проблему.
Заниматься operator new() нужно тогда и только тогда, когда профайлер показал, что они узкое место, а оптимизация очень нужна. Кстати, malloc() ты не перегрузишь. И вообще, зачем мешать в одной программе и malloc() и new?

glibc позволяет   

bsa:  Спасибо.
Да, я понял что, исправлять последствия кривого ума, не лучший выход.
Вот, размышляю, над тем как правильней побороть сию проблему...
Профайлер говорит что, бОльшая часть времени уходит на, соответственно:

Но я уже и так, заменил стандартные на макросы. Помогло, на 14%.

Есть еще один, абсолютно правильный выход...но работы ооооо как много.

Продолжаю размышлять....

У Александреску это описано подробно. И неплохую реализацию (с перегрузкой new и delete) содержит библиотека loki. 

andrew_121, думаю, стоит подумать о сокращении количества вызовов этих функций путем изменения алгоритма. Если невозможно изменить алгоритм, то стоит максимально ускорить эти функции (например, считывая за единицу времени не символ, а четыре (восемь, шестнадцать...) символа).
Если не поможет, то только смена железа.

не глянуть ли в сторону std::string? там хотя бы бесполезных поисков конца строки нет...
Но это так, слезы: действительно на алгоритм посмотреть надо, может и не нужны там все эти strcpy и strdup ;)
  был у нас в одном проекте страшный тормоз. профайлер показал, что миллион раз вызывается некая функция. Это для данных порядка 100 элементов. после переделки способа обработки функция та стала вызываться ... в 1000 раз реже.

baldina: Прога писана не мной. А предидущим прогером. Прога жутко большая.
Я заменил вызовы стандартных функций, макросами, помогло.
Но радикально перепахивать код не охота...

Это сообщение отредактировал(а) andrew_121 - 10.6.2008, 01:39

andrew_121, профайлер должен показать полный стек вызовов этих процедур. Найди наиболее часто встречающуюся ветку и ее переделай.