Текущий архив: 2007.09.30;
Скачать: CL | DM;
Вниз
Работа с памятью. Найти похожие ветки
← →
Riply © (2007-09-06 03:19) [0]Здравствуйте !
Допустим, нам требуется часто и много раз выделять блоки памяти и освобождать их.
Пусть все блоки будут одинакового размера.
Какие могут быть варианты реализации ?
Можно написать самой простенький класс.
Например, выделить большой кусок и выдавать его сегменты по требованию,
помечая их как занятые. При освобождении сегмента помечать его как свободный.
Но, как показывает мой опыт, все давно уже написано до нас.
И есть уверенность, что существует более красивое(оптимальное, рациональное) решение.
По советам старших, пыталась посмотреть с чем едят LookasideList"ы, но мой
пыл быстро охладило отсутствие на моем компьютере таких библиотек как Wdm, Ntddk, or Ntifs.
С какой стороны можно подступиться к решению этой задачи ?
← →
Германн © (2007-09-06 03:24) [1]Удалено модератором
Примечание: Флуд
← →
Riply © (2007-09-06 03:28) [2]Удалено модератором
Примечание: Флуд
← →
Riply © (2007-09-06 03:30) [3]Удалено модератором
Примечание: Флуд
← →
Германн © (2007-09-06 03:39) [4]Удалено модератором
Примечание: Флуд
← →
Turbouser © (2007-09-06 03:41) [5]> [0] Riply © (06.09.07 03:19)
Для чего это? Зачем такие извращения?
← →
Германн © (2007-09-06 03:46) [6]Удалено модератором
Примечание: Флуд
← →
Turbouser © (2007-09-06 04:31) [7]Удалено модератором
Примечание: Флуд
← →
Riply © (2007-09-06 04:37) [8]> [5] Turbouser © (06.09.07 03:41)
> Для чего это? Зачем такие извращения?
А что тебя смущает и где ты увидел извращения ?
P.S.
Сейчас как придут модераторы и как зарежут ветку за злостный флуд :)
Что тогда делать будем ?
← →
Turbouser © (2007-09-06 04:40) [9]Удалено модератором
Примечание: Флуд
← →
Riply © (2007-09-06 05:16) [10]> [9] Turbouser © (06.09.07 04:40)
> Ок. Ограничимся одним вопросом - для чего это?
Допустим ты копируешь файл по кусочкам.while Condition do
begin
ReadFile(Buffer,..
WriteFile(Buffer,..
end
Тебе же не придет в голову на каждом шаге цикла использовать GetMem/FreeMem для Buffer ?
Нет, ты заранее выделишь Buffer нужного размера и будешь его использовать.
Ну а теперь вообразим, что нам нужен для работы не один буфер (сколько - неизвестно)
и их количество меняется в ходе работы. Некоторые "освобождаются", другие прибавляются.
Может при освобождении лучше не уничтожать их,
а пометить как пригодные для повторного использования ?
← →
MBo © (2007-09-06 05:19) [11]простая реализация менеджера блоков есть у Бакнелла (книга Фунд. Алгоритмы)
исходники
http://www.boyet.com/FixedArticles/DADSBook.html
стоит только проверить - вдруг Fastmem-овский менеджер памяти не хуже справляется
← →
Сергей М. © (2007-09-06 09:06) [12]
> Riply © (06.09.07 03:19)
Я так понял что встроенный в RTL BorlandMM тебя по каким-то причинам не устраивает ?
← →
Riply © (2007-09-06 09:07) [13]> [12] Сергей М. © (06.09.07 09:06)
> Я так понял что встроенный в RTL BorlandMM тебя по каким-то причинам не устраивает ?
Очень стыдно, но спрошу: кто это и с чем его едят ?
← →
MBo © (2007-09-06 09:17) [14]>кто это и с чем его едят ?
BorlandMM - dтроенный в Дельфи менеджер памяти.
http://rsdn.ru/article/Delphi/memmanager.xml
В последних версиях - FastMM
← →
Сергей М. © (2007-09-06 09:17) [15]
> кто это
RTL - Run-Time Library
BorlandMM (BMM) - менеджер памяти разработки Борланда, так или иначе встраиваемый по умолчанию в приложения и библиотеки, разрабатываемые в среде Delphi и BCB. Тот самый менеджер, к которому по умолчанию происходит обращение при явном или неявном вызове GetMem/ReallocMem/FreeMem
← →
Riply © (2007-09-06 09:24) [16]>[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:25) [17]
> в нем есть работа с блоками ?
Что значит "работа с блоками" ? Поясни ..
← →
Riply © (2007-09-06 09:33) [18]> [17] Сергей М. © (06.09.07 09:25)
> Что значит "работа с блоками" ? Поясни ..
Ну то, что я пыталась описать в [0] Riply © и [10] Riply ©.
Мне надо очень часто и много раз создавать и уничтожать блоки памяти одинакового размера.
Сколько их используется в данный момент времени в программе - непредсказуемо.
Вариант каждый раз когда блок понадобился использовать GetMem и FreeMem, когда он больше
не нужен, меня не устраивает. Я хочу не уничтожать блок (FreeMem), а подождать
следующего "запроса" и использовать его повторно.
Не очень сумбурно ?
← →
Сергей М. © (2007-09-06 09:51) [19]
> Riply © (06.09.07 09:33) [18]
Вообще-то BMM как раз и "заточен" под высокопроизводительную работу с множеством блоков малого размера ..
> то, что я пыталась описать в [0] Riply © и [10] Riply ©.
То что ты там пыталась "описать" - это как раз и реализует практически любой прикладной MM, в т.ч. BMM, FastMM, MSMM ..
← →
Anatoly Podgoretsky © (2007-09-06 09:54) [20]> Riply (06.09.2007 09:33:18) [18]
Ну это же не проблема, веди свой список и используй блоки повторно - пул блоков.
А чем все таки не устраивает GetMem и FreeMem - операция быстрая и при фиксированых блоках память не разрастается.
← →
Сергей М. © (2007-09-06 10:03) [21]
> Вариант каждый раз когда блок понадобился использовать GetMem
> и FreeMem, когда он больше
> не нужен, меня не устраивает
Почему ?
BMM при FreeMem не отдает блок в кучу, а как раз и помечает его как незанятый, производя при необходимости и возможности "сборку мусора" (Garbage Collection, GC).
Основные "тормоза" приходятся как раз на GC, поскольку это нетривиальная операция. Отключить ее в BMM не представляется возможным, и если это критично, то тогда есть резон обратить взор на другие MM, где этот механизм отсутствует или управляем, а также реализован механизм индексации для ускорения поиска подходящих по размеру блоков. Можно так же "выковырять" код BMM в отдельный юнит, доработать его в части требований по наличию и управляемости GC и заменить им штатный MM (см. справку по TMemoryManager)
← →
Riply © (2007-09-06 10:04) [22]> [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:11) [23]Сергей М. прав. Стандартный менеджер памяти именно так и работает. Сначала выделяет большой блок памяти, а потом раздает указатели на его части по требованию. FastMM - как альтернатива.
← →
Инс © (2007-09-06 10:16) [24]
> А в рекурсии ((с) masterdelphi) не рекомендуется использовать
> многократное вложение try/finally
За переполнения стека боитесь? Одни блок try-finally это лишь 8 лишних байт в стеке.
← →
Сергей М. © (2007-09-06 10:18) [25]
> Riply © (06.09.07 10:04) [22]
Если ты работаешь с блоками заранее определенного фиксированного размера, то дефрагментация тебе друг, а не враг)
Другой вопрос что отсутствие в BMM индексации блоков сводит на нет преимущества дефрагментированной памяти.
← →
Anatoly Podgoretsky © (2007-09-06 11:51) [26]> Riply (06.09.2007 10:04:22) [22]
А ты обрати внимание на слова "при фиксированых блоках память не разрастается."
← →
Riply © (2007-09-06 16:00) [27]Мастера так дружно встали стеной на защиту BMM,
что посеяли сомнения в рядах морально неустойчивых противников :)
Так какое будет резюме ?
Не городить огород, использовать GetMem, FreeMem, и быть счастливой ?
← →
Инс © (2007-09-06 16:07) [28]FastMM поставьте, там вопрос с фрагментацией, насколько мне известно, решен.
← →
Сергей М. © (2007-09-06 16:07) [29]
> Не городить огород, использовать GetMem, FreeMem, и быть
> счастливой ?
Можно и погородить, если это будет оправдано, но ты же по сей момент так и не сказала о размере своих блоков ..
Еще раз - BMM при всех его прелестях и недостатках ориентирован на управление большим числом блоков малого размера. Т.е. он отнюдь не универсален, но для типовых задач, решаемых в Делфи, он подходит как нельзя лучше.
← →
Сергей М. © (2007-09-06 16:12) [30]
> Riply © (06.09.07 16:00) [27]
В конце-концов, если реаллокация не требуется и предусмотрен стек достаточного размера, пара простейших спец.процедур в (дюжину строк каждая), работающих со стеком, существенно ускорят производительность MM-операций.
← →
Riply © (2007-09-06 16:19) [31]>[29] Сергей М. © (06.09.07 16:07)
> Можно и погородить, если это будет оправдано,
> но ты же по сей момент так и не сказала о размере своих блоков ..
Размер блока = максимум(размер файловой записи в MFT, размер кластера) плюс 32.
В 99.99 случаях из 100 размер файловой записи равен 1024
← →
Сергей М. © (2007-09-06 16:31) [32]
> Riply © (06.09.07 16:19) [31]
> В 99.99 случаях из 100 размер файловой записи равен 1024
>
Ну если он и в оставшихся 0.01% будет кратен 4, то может и есть смысл оставить ВММ .
Впрочем, попробуй оценить сама работу различных ММ на твоих конкретных данных при конкретных условиях (условия и данные при оценке д.б. одинаковыми для всех тестируемых тобой ММ). Реаллокация в экперименте пусть не участвует, коль скоро она тебе не нужна.
Для затравки возьми BMM, FastMM, MSMM (в составе msvcrt.dll, msvcrXX.dll)..
← →
Anatoly Podgoretsky © (2007-09-06 16:35) [33]> Riply (06.09.2007 16:00:27) [27]
Руки у тебя чешутся
Страницы: 1 вся ветка
Текущий архив: 2007.09.30;
Скачать: CL | DM;
Память: 0.56 MB
Время: 0.041 c
