Менеджер памяти. (он же сборщик мусора или куча)

← →
Serge Grivachenko (2002-11-09 00:46) [0]

Не приходилось ли сталкиваться с такой проблемой: При выделении памяти стандартным менеджером памяти иногда случается так, что две области памяти оказываются далеко друг от друга. В результате при работе возникает множество ошибок страниц, что замедляет работу. Существует альтернативный менеджер (рекомендованный для KOL) он основан на API вызовах, которые и работают с кучей. Такой ошибки там нет (!), но время на выделение памяти затрачивается много, и все алгоритмы, где постоянно выделяется память значительно тормозятся.

Проблема: как при этом создавать быстрые и компактнаые программы?

Если кто-нибудь сталкивался с этой проблемой - поделитесь опытом, если нет - то ответьте, как эту проблему можно решать.
У меня уже мозгов не хватает. Рад буду услышать любые соображения по этому поводу.

← →
Fantasist (2002-11-16 09:33) [1]

Написать свой менеджер памяти. :)
Смысл в том, чтобы сразу выделить большой кусок памяти, и новые обекты просто размещать там(вызвав конструктор). Конечно, надо самому контролировать занятость памяти. Такую фичу любят делать в виде связанного списка страниц(своих страниц). Не знаю как это будет с реализацией для Object Pascal, но С++ это дело довольно регулярное. В конце концов, asm есть, если на паскале некоторые моменты не будут склеиваться хорошо.

← →
Serge Grivachenko (2002-11-21 16:17) [2]

Дальнейшие изыскания в этой области натолкнулись на следующие:
В основном все хорошо работает (без page faults, включая и КОЛ) на Windows NT.

А на других Виндах иногда есть проблемы. Я думаю здесь причина в менеджере виртуальной памяти виндов. И в том, что сами эти винды много занимают оперативки :)

Моя библиотечка, из-за которой проблема то и возникла, постоянно пытается занимать и освобождать динамическую память. Потому что черт меня дернул передавать в процедуры где ни попадя динамические string"и. Будь они неладны :)

Придется видимо переделывать ее и впредь использовать stringи и динамические массивы аккуратней. Или вообще обойтись без них. (Выделить один раз память (где-нибудь в сегменте данных) и радоваться :) )

Другой вариант - действительно подумать над новым менеджером.

Тогда вопрос - чем плох имеющийся? Какой смысл переписывать?
Что надо улудшить по сравненнию с тем, что уже есть. ?

Почему это рядовой вопрос в C++ там же тоже есть свой malloc, примерно такой же, как GetMem. Чем не устраивает то, что есть в стандартных библиотеках?

← →
Bartov (2002-11-21 20:49) [3]

А может не стоит изобретать велосипед?
Хотя, человек всегда стремится к совершентсву...

← →
Fantasist (2002-11-21 21:53) [4]

> Почему это рядовой вопрос в C++ там же тоже есть свой malloc,
> примерно такой же, как GetMem. Чем не устраивает то, что
> есть в стандартных библиотеках?

Так выделение памяти - это менеджер не того уровня. Свои менеджеры памяти могут выделять память используя тот же malloc - но они могут быть оптимизированны на скорость выделения. Смысл в том, чтобы сразу выделить большой кусок памяти, а потом просто раздавать из этого куска память кому надо. Можно выделить вообще статический кусок памяти. Идея проста - способов реализации довольно много и она не всегда проста.
В C++ это совсем совсем НЕ рядовой вопрос. Но тем не менее такая вещь используется - ее просто реализовать проще и эффективнее на С++. Практически во всех серьезных книгах по С++ рассматриваются вопросы управление памятью. Потому как можно еще кое-что полезное с ней сделать кроме быстрого выделения (сборщик мусора, уплотнение(дефрагментация), быстрый доступ)

← →
Serge Grivachenko (2002-11-22 11:35) [5]

И malloc и GetMem - Выделяют сначала большой кусок памяти с помощью API функции VirtualAlloc, а затем раздают его. Скорость у них вполне приличная.

> можно еще кое-что полезное с ней сделать кроме быстрого
> выделения (сборщик мусора, уплотнение(дефрагментация), быстрый
> доступ)

Вот это уже интересней. Тогда есть ли где-нибудь ссылка на доки, где написано, для чего из вышеперечисленного изобретен GetMem и malloc? Т.е какого "уровня" мендежер памяти malloc? На что он с оптимизирован?

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

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

Так может стоит открыть где-нибудь ветку по управлению памятью? Возможно не в этом форуме. Посоветуйте, где лучше?
И кто за это?

← →
Fantasist (2002-11-22 21:24) [6]

> И malloc и GetMem - Выделяют сначала большой кусок памяти
> с помощью API функции VirtualAlloc, а затем раздают его.
> Скорость у них вполне приличная.

Это не переносимо, если говорить о malloc - не на всех платформах есть Win API. Конечно, в любом случае можно реализовать стандартные менеджеры памяти которые будут себя вести так, но чем более умен стандартный менеджер памяти - тем больше времени он тратит на управление ей, а это оставляет меньше возможностей для собственной оптимизации. Стандартный менеджер то не знает, с чем он имеет дело, поэтому память во всех случаях он выделяет по тому же принципу.Но вы то знаете. Скажем, вы знаете, что есть у вас большие объекты, которые появляются и исчезают редко, и есть маленькие объекты, которые создаются и разрушаются часто. Эффективнее было бы выделить два пула памяти и для первого случая возможно существует некоторый оптимальный размер блоков для объектов, который вы можете предположить, ибо знаете их размер. То есть если эти объекты занимают от 2000 до 4000 байт, то логично выделять память блоками кратными 4000.Для маленьких наоборот, можно сразу выделить скажем даже на стеке(в сегменте данных) блок этак в 4096 байт и просто использовать его, если вы уверенны, что этого объема вам хватит. И не надо будет забивать остальную динамическую память мелкими разбрасанными везде объектами.

Проблема в том, что в делфи это не так просо. Вам скорее всего придется пытаться изменить дельфовые системные библиотеки, если вы хотите менеджить память для работы с дельфийскими строками. В С++ стандартная библиотека уже предполагает, что вы возможно захотите написать собственный менеджер и предоставляет для этого возможности.

> Вот это уже интересней. Тогда есть ли где-нибудь ссылка
> на доки, где написано

Нет прямо так ссылок не найду. В основном я читал об этом у Страуструпа, Элджера и Коплиена кажись.

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

Да. Но я к тому, что я читал несколько книг про использования Делфи - нигде не было про управление памятью. Читал несколько книг про С++, в каждой был раздел про управление памятью. Может я, конечно, не видел не одной серьезной книги по Делфи, конечно. Назовите тогда, буду благодарен.

> Так может стоит открыть где-нибудь ветку по управлению памятью?
> Возможно не в этом форуме. Посоветуйте, где лучше?
> И кто за это?

Так в любом месте. Я бы пошел в конференцию delphi.ru, если вы о Делфи. А если о С++ то те же конференции, и я бы еще поднял на rsdn.ru. Там такие темы любят. :) Здесь на delphi.mastak.ru слишком много тем, и в независимости насколько она серьезная, скорее всего быстро убежит вниз.

Менеджер памяти. (он же сборщик мусора или куча) Найти похожие ветки