TMemoryStream

← →
Тимохов © (2004-05-27 15:07) [0]

При изучении данного класса появились вопросы:

1. Почему память выделяется из кучи процесса, а не стандартными средствами менеджера памяти дельфи?

2. Какой грубинный смысл выделения памяти из кучи?

Заранее благодарен.

← →
Smithson © (2004-05-27 15:51) [1]

1. См исходники :)
2. support@borland.com ^))

← →
Тимохов © (2004-05-27 15:54) [2]

> 1. См исходники :)

И?
Там явное обращение к globalalloc, т.е. к куче.
Почему не к getmem?

Думаю здесь есть логика, которую интересно было бы понять - не дураки же обсуждаемый класс писали :)))))

← →
Digitman © (2004-05-27 15:57) [3]

> 1. Почему память выделяется из кучи процесса, а не стандартными
> средствами менеджера памяти дельфи?

вероятно, потому что блок памяти, аллокируемый под ms, заведомо ожидается Борланлом не как блок памяти под привычную нам "мелочь" (а-ля pointer-указатель, integer-переменная , экз-р объекта и пыр. и пыр.), а как блок памяти ощутимо более солидного размера, под управление каковым штатный встр.менеджер попросту не "заточен"

> 2. Какой грубинный смысл выделения памяти из кучи?

а откуда еще взять блок памяти 7 куча ведь - концептуальное понятие/механизм !

← →
Тимохов © (2004-05-27 16:12) [4]

> а как блок памяти ощутимо более солидного размера, под управление
> каковым штатный встр.менеджер попросту не "заточен"

Да, наверное вы правы.

> а откуда еще взять блок памяти 7 куча ведь - концептуальное
> понятие/механизм !

Вот этого я не совсем понял :))
Можно еше взять имхо из виртуальной памяти. ВП вроде не называется кучей.

← →
WebErr © (2004-05-27 16:17) [5]

О... как клёво звучит... КУЧА!.. по мне так лучше хип говорить, а то ассоциации какие-то нехорошие. А так полностью согласен с Digitman"ом. :)

← →
Digitman © (2004-05-27 16:24) [6]

> Тимохов © (27.05.04 16:12) [4]

любые запросы на аллокацию/реаллокацию/деаллокацию вирт.памяти со стороны прикладного кода, как бы они не выглядели, по умолчанию сводятся к обращению к КУЧЕ... с каждым стартующим процессом система ассоциирует одну кучу по умолачнию

код процесса вол создать еще "кучу куч" (да поростят меня за каламбур) и явно обращаться к созданным кучам с целью управления блоками памяти, потенциально аллокируемым/реаллокируемым/деаллокируемым в них

← →
Тимохов © (2004-05-27 16:26) [7]

Значете, я вот все-таки не очень согласен с тем, что куча лучше подходит, т.к. рассчитана на большие объемы памяти, а дельфовый менеджер памяти - нет.

Я когда читал (Рихтера) про кучи сравнивал быстродействие:
последовательно блоки случайного размера от 100кил до 10мег - в куче, в делфьи, и сам манагер делал на овнове ВП.

Если мне не изменяет память, дельфовый менеджер оказался быстрее. Могу ошибаться, т.к. не придал этому большого внимания. На других величинах требуемой памяти не проверял. Может куча будет быстрее на больших объемах или при других сочетаниях факторов? Надо будет посмотреть.

← →
Тимохов © (2004-05-27 16:28) [8]

> Digitman © (27.05.04 16:24) [6]

> любые запросы на аллокацию/реаллокацию/деаллокацию вирт.памяти
> со стороны прикладного кода, как бы они не выглядели, по
> умолчанию сводятся к обращению к КУЧЕ... с каждым стартующим
> процессом система ассоциирует одну кучу по умолачнию

Я недавно смотрел GetMem.inc. Мое имхо говорит, что вы не совсем правы - там куча используется для таблиц списков. Но основная память аллокируется из виртуальной памяти.

← →
Игорь Шевченко © (2004-05-27 17:19) [9]

Куча удобна тем, что память, выделенную в ней удобно освобождать одним вызовом, также, обращения к менеджеру куч сериализуются, можно установить tracking для слежения за корректностью использования памяти, и т.п. Рихтер это подробнее объясняет.

В итоге, все вызовы сводятся к VirtualAlloc/VirtualFree, разумеется, система не умеет по другому памятью управлять.

← →
Тимохов © (2004-05-28 10:56) [10]

Интересный факт

Дома я провел сравнение скоростей:
1. Штатного манагера памяти Дельфи
2. HeapAlloc
3. GloablAlloc (через movable)

Штатный манагер я поставил в жуткие условия (жуткая фрагментация):
1. 1000 раз последовательно через RallocMem берется память от 10мб с приростом 1кб на каждом шаге.
2. Каждый второй раз из 1000 раз берутся блоки памяти от 1 до 10 байт
3. Из списка (выделен ранее) из 100 блоков размера от 10кб до 1мб удяляется каждый второй.
4. На место удаленных блоков заводится новый размера от 10кб до 1мб (случайно)
Результат выполнения пунта 1 равен 3,3000 сек.

Только пункт 1 (т.е. последовательный Realloc) для HeapAlloc и GlobalAlloc выполняется 30 сек. Т.е. в 10 дольше.

Я еще помучал еще штатный манагер - создал по возможности реальную загрузку маленькими блоками (т.е. как на самом деле бывает). Но более 5 секунд у меня никак не вышло.

Вывод.
Кучи работают в среднем 10 раз медленнее. Для меня осталось непонятным почему в TMemoryStream идет использование кучи.

ЗЫ. Зачем мне нужно это знать? Таков мой стиль изучения - чтение между строк - что реально имелось в виду. Понимая недокументированные фишки - растешь. ИМХО.

ЗЫЫ. Вопроса я по сути здесь не задая т.к. имхо кроме борланда вряд ли это кто точно значет - зачем куча. Это просто факт сравнения скростей (может не все этого делали).

← →
Игорь Шевченко © (2004-05-28 11:36) [11]

Тимохов © (28.05.04 10:56)

А ты статью в RSDN читал, как Borland Memory Manager работает ?

← →
Тимохов © (2004-05-28 11:41) [12]

читал.
да я в общем то и getmem.inc почти (до конца сил не хватило) изучил.

Вопрос к чему?
Я так полагаю, что вы намекаете на то, что в манагере памяти может оказаться недостаточно места, тогда как в куче windows всегда его будет в достатке?

← →
wicked © (2004-05-28 11:49) [13]

вставлю свои 5 копеек - многие АПИшные ф-ции требуют блок памяти, выделенный через GlobalAlloc (например, mmioOpen)... а поскольку TMemoryStream как раз и выделяет через эту функцию, то его Memory удобно передавать таким функциям...

> wicked © (28.05.04 11:49) [13]

Вот.
В этом я думаю я есть суть.

В самом вопросе я хотел предположить, что так сделано, чтобы "быть ближе к windows". Но т.к. не смог объяснить, что такое "ближе", то не предположил этого.

> Кучи работают в среднем 10 раз медленнее. Для меня осталось
> непонятным почему в TMemoryStream идет использование кучи.

думаю, это связано с

Memory allocated by HeapAlloc is not movable. Since the memory is not movable, it is possible for the heap to become fragmented.

Борланд, вероятно, рассуждал так :
для TMemoryManager проигрыш в скорости аллокации/реаллокации компенсируется заметным выигрышем в скорости доступа к аллокированным не перемещаемым блокам кучи;запись в TMemoryManager, возможно, и не есть максимально производительная, зато чтение (как вроде бы чаще используемое) с лихвой компенсирует не слишком высокую эффективность записи

imho

GlobalAlloc вообще-то устаревшая функция и используется для совместимости старых программам.

"The global functions are slower than other memory management functions and do not provide as many features. Therefore, new applications should use the heap functions. However, the global functions are still used with DDE, the clipboard functions, and OLE data objects."

Поэтому утверждение wicked © (28.05.04 11:49) мягко говоря, сомнительное.

Спасибо за обсуждение.

Думаю мне придется ограничится коллективными предположениями :)))

Все же у меня создается ощущение, что только борланд знает ответ :)))

ОФФ.
Не у кого не было опыта задавания вопросов именно разработчикам борланда? Можно ли это сделать через их форум?

Тимохов © (28.05.04 12:15)

> Не у кого не было опыта задавания вопросов именно разработчикам
> борланда?

Был. Только ответили не они, а представители TeamB

> Можно ли это сделать через их форум?

Конечно. Выбрать нужный форум news-client"ом на forums.borland.com и задать вопрос. Регистрация не требуется, общение, разумеется на английском. :)

TMemoryStream Найти похожие ветки