Узкое место в распределении / выделении памяти?

Question

Насколько узким местом является распределение / освобождение памяти в типичных реальных программах? Ответы от любой программы, где производительность обычно имеет значение, приветствуются. Достаточно ли бывают приличные реализации сборки malloc / free / garbage, чтобы это было лишь узким местом в нескольких угловых случаях, или для большинства критически важного программного обеспечения было бы значительно выгоднее пытаться уменьшить объем выделяемой памяти или иметь более быстрый malloc / free / реализация сборки мусора?

Примечание: я не говорю о вещах в реальном времени. Под критичностью к производительности я имею в виду вещи, в которых пропускная способность имеет значение, но задержка не обязательно.

Редактировать: Хотя я упоминаю malloc, этот вопрос не предназначен для C / C ++.

Answer 1

Почти все вы от базы, если вы говорите о куче Microsoft. Синхронизация легко обрабатывается, как и фрагментация.

Текущей перферированной кучей является LFH, ( LOW FRAGMENTATION HEAP), это значение по умолчанию в Vista + OS и может быть настроено на XP, через gflag без особых проблем

Легко избежать каких-либо проблем с блокировкой / блокировкой / конфликтом / перебросом шины и многим другим с

HEAP_NO_SERIALIZE

опция во время HeapAlloc или HeapCreate. Это позволит вам создавать / использовать кучу, не вступая в блокированное ожидание.

Я бы порекомендовал создать несколько куч, с HeapCreate, и определить макрос, возможно, mallocx (enum my_heaps_set, size_t);

было бы хорошо, конечно, вам нужен realloc, бесплатный также для установки в качестве подходящего. Если вы хотите получить фантазию, сделайте free / realloc автоматически определяющим, какой дескриптор кучи самостоятельно, путем оценки адреса указателя или даже добавив некоторую логику, чтобы позволить malloc определить, какую кучу использовать, на основе его идентификатора потока, и построив иерархия куч для каждого потока и общих глобальных куч / пулов.

Куча * API-интерфейсы называются внутренне malloc / new.

Вот хорошая статья о некоторых проблемах с динамическим управлением памятью , с некоторыми еще более приятными ссылками . Для обработки и анализа активности кучи.

Answer 2

Другие рассказали о C / C ++, поэтому я просто добавлю немного информации о .NET.

В .NET выделение кучи, как правило, происходит очень быстро, поскольку это всего лишь вопрос захвата памяти в нулевой части кучи. Очевидно, что это не может продолжаться вечно, и именно здесь происходит сборка мусора. Сборка мусора может существенно повлиять на производительность вашего приложения, поскольку пользовательские потоки должны быть приостановлены во время сжатия памяти. Чем меньше полных сборов, тем лучше.

Существуют различные способы влияния на рабочую нагрузку сборщика мусора в .NET. Как правило, если у вас много ссылок на память, сборщику мусора придется выполнять больше работы. Например. Реализуя граф, используя матрицу смежности вместо ссылок между узлами, сборщик мусора должен будет анализировать меньше ссылок.

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