Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Работа с памятью.

Страницы: 1 2 >
Riply © (2007-09-06 03:19:00)
Здравствуйте !
Допустим, нам требуется часто и много раз выделять блоки памяти и освобождать их.
Пусть все блоки будут одинакового размера.
Какие могут быть варианты реализации ?
Можно написать самой простенький класс.
Например, выделить большой кусок и выдавать его сегменты по требованию,
помечая их как занятые. При освобождении сегмента помечать его как свободный.
Но, как показывает мой опыт, все давно уже написано до нас.
И есть уверенность, что существует более красивое(оптимальное, рациональное) решение.
По советам старших, пыталась посмотреть с чем едят LookasideList'ы, но мой
пыл быстро охладило отсутствие на моем компьютере таких библиотек как Wdm, Ntddk, or Ntifs.
С какой стороны можно подступиться к решению этой задачи ?

Anatoly Podgoretsky (2007-09-06 16:35:00) [1]
> Riply (06.09.2007 16:00:27) [27]

Руки у тебя чешутся

Сергей М. (2007-09-06 16:31:00) [2]

> Riply © (06.09.07 16:19) [31]

> В 99.99 случаях из 100 размер файловой записи равен 1024
>

Ну если он и в оставшихся 0.01% будет кратен 4, то может и есть смысл оставить ВММ .

Впрочем, попробуй оценить сама работу различных ММ на твоих конкретных данных при конкретных условиях (условия и данные при оценке д.б. одинаковымидля всех тестируемых тобой ММ). Реаллокация в экперименте пусть не участвует, коль скоро она тебе не нужна.

Для затравки возьми BMM, FastMM, MSMM (в составе msvcrt.dll, msvcrXX.dll)..

Riply (2007-09-06 16:19:00) [3]
>[29] Сергей М. © (06.09.07 16:07)
> Можно и погородить, если это будет оправдано,
> но ты же по сей момент так и не сказала о размере своих блоков ..

Размер блока = максимум(размер файловой записи в MFT, размер кластера) плюс 32.
В 99.99 случаях из 100 размер файловой записи равен 1024

Сергей М. (2007-09-06 16:12:00) [4]

> Riply © (06.09.07 16:00) [27]

В конце-концов, если реаллокация не требуется и предусмотрен стек достаточного размера, пара простейших спец.процедур в (дюжину строк каждая), работающих со стеком, существенно ускорят производительность MM-операций.

Сергей М. (2007-09-06 16:07:00) [5]

> Не городить огород, использовать GetMem, FreeMem, и быть
> счастливой ?

Можно и погородить, если это будет оправдано, но ты же по сей момент так и не сказала о размере своих блоков ..

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

Инс (2007-09-06 16:07:00) [6]
FastMM поставьте, там вопрос с фрагментацией, насколько мне известно, решен.

Riply (2007-09-06 16:00:00) [7]
Мастера так дружно встали стеной на защиту BMM,
что посеяли сомнения в рядах морально неустойчивых противников :)
Так какое будет резюме ?
Не городить огород, использовать GetMem, FreeMem, и быть счастливой ?

Anatoly Podgoretsky (2007-09-06 11:51:00) [8]
> Riply (06.09.2007 10:04:22) [22]

А ты обрати внимание на слова "при фиксированых блоках память не разрастается."

Сергей М. (2007-09-06 10:18:00) [9]

> Riply © (06.09.07 10:04) [22]

Если ты работаешь с блоками заранее определенного фиксированного размера, то дефрагментация тебе друг, а не враг)

Другой вопрос что отсутствие в BMM индексации блоков сводит на нет преимущества дефрагментированной памяти.

Инс (2007-09-06 10:16:00) [10]

> А в рекурсии ((с) masterdelphi) не рекомендуется использовать
> многократное вложение try/finally

За переполнения стека боитесь? Одни блок try-finally это лишь 8 лишних байт в стеке.

Инс (2007-09-06 10:11:00) [11]
Сергей М. прав. Стандартный менеджер памяти именно так и работает. Сначала выделяет большой блок памяти, а потом раздает указатели на его части по требованию. FastMM - как альтернатива.

Riply (2007-09-06 10:04:00) [12]
> [20] Anatoly Podgoretsky © (06.09.07 09:54)
> Ну это же не проблема, веди свой список и используй блоки повторно - пул блоков.
Проблеммы нет. Просто я думала, что это уже где-то реализовано.
>А чем все таки не устраивает GetMem и FreeMem -
>операция быстрая и при фиксированых блоках память не разрастается.
Не устраивает по нескольким причинам:
1. Здесь на форуме (ветку не помню) читала, что частое испльзование GetMem\FreeMem
ведет к фрагментации памяти.
2. Я работаю с рекурсивными процедурами. Рука не поднимается не обрамлять
GetMem\FreeMem блоками try/finally.
А в рекурсии ((с) masterdelphi) не рекомендуется использовать многократное вложение try/finally
3. Ну и наконец, простой тестовый пример (к сожалению я его уже стерла) показывает
существенный выигрыш при выделении "большого" блока и обращениям к его "сегментам"
по сравнению с использованием каждый раз GetMem\FreeMem

Сергей М. (2007-09-06 10:03:00) [13]

> Вариант каждый раз когда блок понадобился использовать GetMem
> и FreeMem, когда он больше
> не нужен, меня не устраивает

Почему ?

BMM при FreeMem не отдает блок в кучу, а как раз и помечает его как незанятый, производя при необходимости и возможности "сборку мусора" ( Garbage Collection, GC).

Основные "тормоза" приходятся как раз на GC, поскольку это нетривиальная операция. Отключить ее в BMM не представляется возможным, и если это критично, то тогда есть резон обратить взор на другие MM, где этот механизм отсутствует или управляем, а также реализован механизм индексации для ускорения поиска подходящих по размеру блоков. Можно так же "выковырять" код BMM в отдельный юнит, доработать его в части требований по наличию и управляемости GC и заменить им штатный MM (см. справку по TMemoryManager)

Anatoly Podgoretsky (2007-09-06 09:54:00) [14]
> Riply (06.09.2007 09:33:18) [18]

Ну это же не проблема, веди свой список и используй блоки повторно - пул блоков.
А чем все таки не устраивает GetMem и FreeMem - операция быстрая и при фиксированых блоках память не разрастается.

Сергей М. (2007-09-06 09:51:00) [15]

> Riply © (06.09.07 09:33) [18]

Вообще-то BMM как раз и "заточен" под высокопроизводительную работу с множеством блоков малогоразмера ..

> то, что я пыталась описать в [0] Riply © и [10] Riply ©.

То что ты там пыталась "описать" - это как раз и реализует практически любой прикладнойMM, в т.ч. BMM, FastMM, MSMM ..

Riply (2007-09-06 09:33:00) [16]
> [17] Сергей М. © (06.09.07 09:25)
> Что значит "работа с блоками" ? Поясни ..
Ну то, что я пыталась описать в [0] Riply © и [10] Riply ©.
Мне надо очень часто и много раз создавать и уничтожать блоки памяти одинакового размера.
Сколько их используется в данный момент времени в программе - непредсказуемо.
Вариант каждый раз когда блок понадобился использовать GetMem и FreeMem, когда он больше
не нужен, меня не устраивает. Я хочу не уничтожать блок (FreeMem), а подождать
следующего "запроса" и использовать его повторно.
Не очень сумбурно ?

Сергей М. (2007-09-06 09:25:00) [17]

> в нем есть работа с блоками ?

Что значит "работа с блоками" ? Поясни ..

Riply (2007-09-06 09:24:00) [18]
>[11] MBo © (06.09.07 05:19)
>исходники http://www.boyet.com/FixedArticles/DADSBook.html
Скачала, смотрю, разбираюсь. Спасибо.
> [14] MBo © (06.09.07 09:17)
> BorlandMM - dтроенный в Дельфи менеджер памяти.
> http://rsdn.ru/article/Delphi/memmanager.xml
> В последних версиях - FastMM
> [15] Сергей М. © (06.09.07 09:17)
> BorlandMM (BMM) - менеджер памяти разработки Борланда,

Спасибо. Пойду смотреть. А в нем есть работа с блоками ?

Сергей М. (2007-09-06 09:17:00) [19]

> кто это

RTL - Run-Time Library

BorlandMM (BMM) - менеджер памяти разработки Борланда, так или иначе встраиваемый по умолчанию в приложения и библиотеки, разрабатываемые в среде Delphi и BCB. Тот самый менеджер, к которому по умолчанию происходит обращение при явном или неявном вызове GetMem/ReallocMem/FreeMem

MBo (2007-09-06 09:17:00) [20]
>кто это и с чем его едят ?
BorlandMM - dтроенный в Дельфи менеджер памяти.
http://rsdn.ru/article/Delphi/memmanager.xml
В последних версиях - FastMM

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »