Skip to content
Automatically exported from code.google.com/p/sapmm
Pascal C++
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
README.md
SAPDebugUtils.pas
SAPDefs.pas
SAPDefs_Etalon.pas
SAPErrCodes.pas
SAPInstall.pas
SAPList.pas
SAPNormalBlocks.pas
SAPOSBlocks.pas
SAPOptions.inc
SAPRelease.pas
SAPReportMemoryLeaks.pas
SAPSmallBlocks.pas
SAPSystem.pas
SAPThreadMM.pas
SAPUtils.pas
SAPXRef.pas

README.md

sapmm

Automatically exported from code.google.com/p/sapmm

SapMM is Simple As Possible memory manager for Delphi XE+, designed especially for memory-intensive multithreaded applications. Should also work with other versions of Delphi (may require tiny code modifications). SapMM scales very (I mean VERY) well under multithreaded use. If you use OmniThreadLibrary, you definetely should take a look at SapMM.

To use SapMM simply add to your uses clause SapInstall unit as the first unit of your project (in the dpr file).

NOTE! Currently SapMM supports only 32-bit mode and can not be used with 64-bit applications. Contributors who can add 64-bit support are welcome, any help appreciated.

At the present moment SapMM is well tested only with Delphi XE and XE3 and is used in production (multi-user document flow system) since June 2013. Version 1.01 is stable and can be used in production.

Author of the code is Alexei Nedoria, PM and software guru from Ivanovo, Russia. You can contact him directly via his email ned@iname.com

Current maintainer of the code is Anton Alisov, PM and software developer from Ivanovo, Russia. You can contact me via GoogleCode, email: alan008@bk.ru, Skype: antonalisov.

You can tune up the manager in some ways using SapDefs.pas unit. The most interesting constants here are:

cOSBlockSize - minimal block size, requested from OS as one piece
cMaxOSBlocksInPool - number of freed OS blocks, which are not returned to the OS by your app and stay in memory pool for future reuse. I.e. cOSBlockSize x cMaxOSBlocksInPool is maximum amount of memory your app will always hold for future reuse. Forced pool cleanup may happen in insufficient memory conditions.
You can’t perform that action at this time.