мемори-менеджер в fpc

[devels]

По моим тестам для современных Windows наилучшие показатели имеет самое простое решение на основе HeapAlloc. MM на его основе пишется за пол-часа.

Не знаю какие у вас тесты, но для недолго живущих объектов это тормоз, я пробовал разные настройки и флаги. Родной GetMem и FreeMem у меня работает быстрее.

[coyot.rush]

Принципы работы с памятью в системе Windows32 http://delphiworld.narod.ru/base/mem_win32.html

Windows имеет свою собственную реализацию менеджера кучи, который позволяет приложениям создавать, уничтожать кучи, а также производить с ними операции выделения и освобождения памяти в куче. Кроме того, для каждого вновь создаваемого процесса Windows специально создает кучу по умолчанию, которая используется при работе API функций, а также может быть использована прикладной программой. Все создаваемые Windows кучи потоко-безопасны, то есть существует возможность обращения к одной и той же куче из разных потоков одновременно.

Инженеры компании Borland по видимому не доверяют инженерам компании Microsoft, поэтому каждая программа на Delphi имеет свою собственную реализацию менеджера кучи, которая определена в системных модулях. Такое решение аргументируется инженерами Borland тем, что стандартный менеджер кучи Windows не обеспечивает достаточно эффективную работу с памятью. Конечно, как и любая Windows-программа, программа на Delphi имеет стандартную кучу по умолчанию, которую создает для нее система, однако функции New, Release, GetMem, FreeMem и некоторые другие оперируют с собственной реализацией менеджера куч. Менеджер кучи Delphi резервирует блоки адресного пространства размером 1 Мб, а выделяет блоки реальной памяти размером 16 Кб. Также вы можете написать и установить свою реализацию менеджера куч, если не доверяете ни инженерам Borland, ни инженерам Microsoft - для этого имеются все необходимые функции.

Хотя куча совершенно не предназначена для выделения больших участков памяти, запрос выделения большого участка у кучи не приведет к ошибке. Куча просто перенаправит ваш запрос операционной системе и вернет указатель на выделенный ею участок памяти.

[Max Rusov]

Не знаю какие у вас тесты, но для недолго живущих объектов это тормоз, я пробовал разные настройки и флаги. Родной GetMem и FreeMem у меня работает быстрее.

Возможно, Вы пробовали на старых версиях Windows, с отключенным Low-fragmentation Heap?

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Попробуйте в Vista/Win7 (или включите LFH в XP) - будете удивлены.

[Azeroth]

может быть выложите модуль с ММ, для теста? если он лучше чем родной, даже если только для винды это будет круто.
я думаю, что вызовы в систему всё-таки имеют свою стоимость, и на множестве мелких выделений памяти эта стоимость может сказаться.

[Max Rusov]

Да пожалуйста. В комплекте тест который делает аллокацию - реаллокацию - освобождение памяти.

У меня результаты такие:

На стандартном MM FPC:

Код: Выделить всё

>MemTest 1000000 1024
Blocks: 1000000, max size: 1024, Time: 7082 ms


На MM Windows:

Код: Выделить всё

>MemTest 1000000 1024
Blocks: 1000000, max size: 1024, Time: 889 ms

Как говорится - почувствуйте разницу

[Azeroth]

спасибо, действительно, ваш ММ быстрее фпцешного, и приближается к fastmm (отстаёт в 2раза гдето)
буду использовать, если вы не против
теперь тормозов уже не заметно, можно писать на фпц, и надо мне будет поковыряться в этом направлении, действительно ММ можно написать за полчаса, снимаю шляпу

[devels]

Не знаю какие у вас тесты, но для недолго живущих объектов это тормоз, я пробовал разные настройки и флаги. Родной GetMem и FreeMem у меня работает быстрее.

Возможно, Вы пробовали на старых версиях Windows, с отключенным Low-fragmentation Heap?

http://msdn.microsoft.com/en-us/library ... 85%29.aspx

Попробуйте в Vista/Win7 (или включите LFH в XP) - будете удивлены.

Это конечно хорошо, но с учетом того что у более 50% стоит XP, многие пользователи не увидят на деле никакого быстродействия, у меня же ваш менеджер тормозит в 2-3 раза по сравнению с родным, пользователи могут почувствовать серьезное замедление.

[Max Rusov]

Это конечно хорошо, но с учетом того что у более 50% стоит XP, многие пользователи не увидят на деле никакого быстродействия,

XP точно так-же поддерживает LFH. Я же привел ссылку.

у меня же ваш менеджер тормозит в 2-3 раза по сравнению с родным, пользователи могут почувствовать серьезное замедление.

Слова. А мой тест показывает 10-кратное преимущество. Жду ваш тест

[Azeroth]

Хочу высказаться
я тут почитал исходники ФастММ и родного ФПЦ-шного ММ, микрософтовского и тов. Max Rusov-а естественно исходники не доступны, так вот фастММ на порядок более сложный и вылизаный, чем родной, и наверно и LFH в винде не простая.
таким образом защитники родного ММ вы не правы, для этого можно даже тесты не проводить, просто на код посмотреть

[devels]

Вот мой тест:

Выделение недолго живущих сферических "объектов" (а таких по статистике 90% в программах).
Средне статистический блок на 100 байт. Практически такой же тест как у вас, вид сбоку.

Код: Выделить всё

var
  i,j,t :integer;
  L:Array of Pointer;
  P: Pointer;
begin
  t := GetTickCount;
  SetLength(L, 101);
  for i := 0 to 10000 do
    begin
      for j := 0 to 100 do
      begin
           Getmem(P,100);
           L[j] := P;
      end;

      for j := 0 to 100 do begin
           ReAllocMem(L[j],200);
      end;

      for j := 0 to 100 do
      begin
           Freemem(L[j], 200);
      end;
    end;
  ShowMessage(IntToStr(GetTickCount - t)); 


WindowsMM - 800 mlsec (ноликами не ошибся).
Родной FpcMM - 200 mlsec
FastMM - 125 mlsec

Есть разница? Правда это без LHF, как ее включить в XP я не в курсе, гугл что-то не может ничего внятного ответить. Если скажете как ее включить, проверю и с ней. Но вы представьте, как долго будет работать программа у более 50% пользователей, у которых не включен LHF.

Добавлено спустя 11 минут 2 секунды:
А вот так если использовать пул, класс которого я приводил выше:

Результат - 50 mlsec, что быстрее FastMM в 2,5 раза, и работает с такой же скорость в Fpc.

Код: Выделить всё

  var
  L2: TOriAllocator;
  I,T: Integer;
  j :integer;
  L:Array of Pointer;
  P: Pointer;
begin
  t := GetTickCount;
  SetLength(L, 101);
  L2 := TOriAllocator.Create(100, 10000);
  for i := 0 to 10000 do
    begin
      for j := 0 to 100 do
      begin
           L[j] := L2.Alloc;
      end;

      for j := 0 to 100 do begin
           ReAllocMem(L[j],200);
           ReAllocMem(L[j],100);
      end;

      for j := 0 to 100 do
      begin
           L2.Dispose(L[j]);
      end;
    end;


[Max Rusov]

Правда это без LHF, как ее включить в XP я не в курсе, гугл что-то не может ничего внятного ответить. Если скажете как ее включить, проверю и с ней. Но вы представьте, как долго будет работать программа у более 50% пользователей, у которых не включен LHF.

Я же давал пример (WindowsMM). LFH не надо где-то включать, программа сама его для себя включает, и это влияет только на ее кучу. Начиная с Vista LFH включен по умолчанию.

Вот мой тест:

А теперь замените в своем тесте константные размеры блоков на Random(N). При N = 200 WindowsMM уже имеет 3-х кратное преимущество.

Встроенный FPC-шный менеджер имеет очень непредсказуемые характеристики. При _удачном_ сочетании факторов он может работать быстро, а при неудачном - проседает на несколько порядков. В приложении, которое действительно критично к аллокации больших объемов памяти - он абсолютно неприемлем.

На мой взгляд WindowsMM интегрально имеет лучшие характеристики чем FastMM, особенно в многопоточных приложениях. Кроме того, я не нашел версию FastMM для x64, поэтому, вообще альтернативу для WindowsMM не знаю.