В какой ситуации Статические тарифы Выделения лучше, чем Динамическое Выделение?
Я проходил некоторые решения, принятые для создания Xtreme Xara, графического приложения SVG с открытым исходным кодом. Их решение управления памятью было довольно интригующим мне, так как я наивно принял как очевидное что динамическое выделение по запросу как способ записать объектно-ориентированное приложение.
Объяснение из документации
Как же статические выделения могут быть эффективными?
Если Вы привыкли к большим динамическим структурам данных, это может казаться странным для Вас. Во-первых, все наши объекты (и таким образом размер выделения) намного меньше (в среднем), чем каждое динамическое выделение области в рамках программы, такой как Впечатление. Это означает, что, хотя, вероятно, будет много дыр в памяти, они являются маленькими. Кроме того, мы намного больше выделили объекты в памяти, и таким образом эти дыры быстро заполняются. Кроме того, диспетчеры виртуальной памяти освободят любые страницы памяти, которые не содержат выделений и отдают эту память к операционной системе так, чтобы она могла использоваться снова (или нами, или другой задачей).
Мы извлекаем выгоду значительно из того, что каждый раз, когда мы выделяем память этим способом, мы не должны переносить память. Это доказало узкое место в ArtWorks, который также имел много маленьких выделений, используемых одновременно.еще
Короче говоря, присутствие большого количества маленьких объектов и потребности предотвратить перемещение памяти является причинами, приведенными для выбора статического выделения. У меня нет ясного понимания о причинах упомянутым.
Хотя это говорит о статическом выделении, что я вижу от поверхностного взгляда на код, то, что блок памяти динамично выделяется в приложении, запускаются и поддержанный до концов приложения, примерно моделируя статическое выделение.
Вы могли объяснить, в каком ситуации Статические тарифы Выделения лучше, чем Динамическое Выделение, по запросу чтобы рассмотреть это как основной режим выделения в серьезные приложения?
2 ответа
Это быстрее, потому что вы избегаете накладных расходов на вызов системной процедуры для управления хранилищем. malloc () поддерживает кучу, поэтому для каждого запроса требуется сканирование блока подходящего размера, возможно изменение размера блока, обновление списка блоков, чтобы отметить этот блок как используемый, и т. Д. много мелких предметов, эти накладные расходы могут быть чрезмерными. С помощью статического распределения вы можете создать пул распределения и просто поддерживать простое растровое изображение, чтобы показать, какие области используются. Это предполагает, что каждый объект имеет одинаковый размер, поэтому вы обычно создаете один пул для каждого типа объекта.
Короче говоря, на самом деле не существует такой вещи, как статическое распределение, кроме пространства, выделенного для самих ваших функций и других видов памяти, доступной только для чтения. (Выполните только сборку «gcc -S» и поищите все блоки памяти, если вам интересно.) Если вы создаете и разрушаете объекты, вы выделяете их динамически. При этом ничто не мешает вам жестко контролировать сам механизм распределения.
Это то, что делают такие функции, как mallinfo () и mallopt (), для управления тем, как malloc () творит свою магию. Однако этого может быть недостаточно для вас. Если вы знаете, что все ваши фрагменты будут одинакового размера, вы можете распределять и освобождать гораздо более эффективно. И если вы знаете, что у вас есть 3 размера данных, вы можете сохранить 3 области памяти, каждый со своим собственным распределителем.
Вдобавок ко всему, во время выполнения возникает ситуация, когда процессу не хватает места и ему нужно запрашивать у операционной системы больше - это связано с системным вызовом, который дороже простого увеличения индекса массива. В unix это обычно brk () или sbrk () или что-то подобное. А это может занять драгоценное время.
Другая, более редкая ситуация, может быть, если вам нужно умножить-распределить вещи. Как будто 3 потока должны обмениваться информацией, и только когда все 3 выпускаются, она освобождается. Это что-то нестандартное и обычно не покрывается типичной памятью mallopt () или даже памятью, специфичной для pthread, или блоками мьютексов / семафоров.
Таким образом, если у вас есть проблемы с оптимизацией на высокой скорости или вы работаете во встроенной системе, где вам нужно выжать все, что вы можете из доступной памяти, то «статическое распределение» или, по крайней мере, управление механизмом распределения, может быть путь идти.