Pro jeden svůj velký projekt používám stále Delphi 5. Nedávno jsem i u něj začal používat FastMM - tedy standardní správce paměti z nových Delphi. Za FastMM dostal jeho autor ocenění Delphi spirit za rok 2005. Za co toto významné ocenění udělované autory Delphi dostal?
Pár slov mimo: Delphi pro alokaci veškeré paměti používají vlastní memory manager, ale umožňují aby programátor použil svůj vlastní manager. Těch existuje několik. Původní memory manager byl vyvinut v době Windows 95 a byl mnohem lepší než správa paměti ve Windows 95. Tento manager byl jako standardní použit pro Delphi 2 - 7. Ve verzi Delphi 2006 byl nahrazen právě FastMM protože paměťové poměry jsou od dob Windows 95 jiné (více paměti atd.).
FastMM od Pierre le Riche je tedy open source správce paměti pro Delphi. Ale není to jen tak nějaký správce paměti. Jedná se o tři různé správce paměti v jednom + detekce neuvolněné paměti nebo naopak pokus o vícenásobné uvolnění. Detekce je aktivní jen při běhu z IDE.
Různé velikosti bloků
FastMM rozlišuje mezi třemi velikostmi alokovaných bloků a podle velikosti použije jednu ze tří možností.
Velké bloky (>260K) jsou alokovány přímo operačním systémem a je požadována jejich alokace od vrchu adresového prostoru (kvůli fragmentaci).
Střední (< 260K) a malé (<2.5K) jsou alokovány odspodu. Střední bloky jsou alokovány od OS v blocích 1.25M a jsou FastMM zpravovány jako pool a vráceny aplikaci jak potřebuje. Při uvolňování z aplikace jsou tyto bloky testovány na volné sousedy a spojovány, ale nejsou vraceny hned OS.
Ale většina alokací jsou malé bloky (instance tříd a spol.) - autor tvrdí že až 99%. Zjednodušeně tyto alokace FastMM nespojuje, ale udržuje seznamy uvolněných bloků podle velikosti a podle potřeby je zase vrací aplikaci. Toto velmi šetří čas.
Velmi užitečné je i odchytávání neuvolněných (nebo špatně uvolněných) bloků paměti. Při ukončení programu při běhu z IDE lze zapnout výpis neuvolněných bloků (a při zapnutí FullDebug módu i s adresami kde k problému došlo).
Testujeme rychlost…
Praktické zrychlení závisí na typu programu. Podle mých zkušeností se jedná tak o 3 - 30% v závislosti na způsobu jak program intenzivně používá paměť.
Jako jeden z testů jsem použil 10x načtení cca 1M XML souboru přes TJclSimpleXML ze starší verze JVCL.
program basic;
{$APPTYPE CONSOLE}
uses
fastMM4, SysUtils, Windows, JclSimpleXml;
var
oXML:TJclSimpleXML;
iTick, iTickEnd, x: Cardinal;
begin
iTick := GetTickCount;
for x:= 1 to 10 do
begin
oXML := TJclSimpleXML.Create();
try
oXML.LoadFromFile('testFastMM.xml');
finally
FreeAndNil(oXML);
end;
end;
iTickEnd := GetTickCount;
Writeln(Format('Ticks: %d', [iTickEnd - iTick]));
end.
Testovací programy se liší jen v uses, kde fastMM4 zapíná FastMM. Nic jiného se nemění. Znovu opakuji, že z IDE jsou aktivní detekce leaků a tj. memory manager neběží na plný výkon.
V uvedeném případě byl počet tiků pro verzi s FastMM cca 6000 a bez FastMM cca 9000. Ale toto byl velmi extrémní případ.
Někdy příště si ukážeme jak použít FastMM pro detekci chyb v programu (nejčastěji neuvolnění paměti).
RSS