Board index » delphi » Re: Memory Managers

Re: Memory Managers


2005-12-21 01:11:14 AM
delphi135
1) Which is your favourite Memory Manager?
Surely FastMM4
2) Why do you preffer this one over the others?
Well, it fast than default memory manager, you can see already when IDE are
loaded it cut the loading time.
the most useful one is it can detect our memory leak.
3) How long are you using this Memory Manager?
Since it became popular <g>
4) Did you have any bad experience using it?
No, this is very helpful to me at least, and i think others too.
Thanks for Pierre :)
 
 

Re: Memory Managers

Danijel Tkalcec [RTC] said...
Quote
I can only guess that higher memory usage with FastMM is resulted to
higer memory fragmentation,
nope.
Quote
but it could also result from additional debug information used by
FastMM to detect memory leaks.
much closer to truth.
I'd suggest, rather than guess, you search/post in BASM group, as
MM Challenge was ongoing technical discussion there for well over
a year. Issues of performance, fragmentation <etc.>have been
discussed in detail.
I'd point out FMM has been adopted by Borland, and used in D'-06.
--
Regards:
Jim McKay
"If English was good enough for Jesus Christ, it's
good enough for us."
- Miriam Amanda "Ma" Ferguson (1875-1961),
Governor of Texas (1925-1927, 1933-1935)
From speech advocating barring foreign language teaching
Posted with XanaNews: Ver: 1.17.6.6
 

Re: Memory Managers

I also think that FastMM is an excellent replacement for the standard memory
manager, because it helps finding memory leaks in applications.
But, in my tests in with multithreaded applications (Client and Server using
260 running threads), FastMM4 used up to 3 times the ammount of memory
needed by BucketMem.
I've done this "memory usage test" a number of times, to make sure it wasn't
caused by some random chance. And in all my tests, FastMM4 reserved more
than 240 MB, while BucketMem was comfortable with less than 90 MB.
I can only guess that higher memory usage with FastMM is resulted to higer
memory fragmentation, but it could also result from additional debug
information used by FastMM to detect memory leaks.
From what I have read about BucketMem, it is designed to reduce memory
fragmentation in multithreaded apps, which makes this a perfect candidate
for high-load multithreaded Servers.
In any case, here's what Robert Houdart (author of BucketMem) wrote ...
---------------
BucketMem is a replacement Memory Manager for Delphi 5,6,7,2005 and Kylix
that does not suffer
from fragmentation and delivers much better performance in a
multi-threaded application.
HOW TO USE: Simply add BucketMem as the very first unit in your project
(dpr) file.
The memory management is performed at 3 levels:
1) the V-Block level that allocates OS memory chunks of 256 kB..1024 kB
of committed memory
2) each V-Block is divided into "Sheets" of 16 kB..144 kB
3) each "Sheet" is used to create memory blocks of a given size (16
bytes up to 144 kB)
The sheets are managed by "buckets".
BucketMem uses about 50 buckets that each deliver memory blocks of a given
size.
A Bucket
- manages a number of Sheets in a double-linked list
- has an ActiveSheet out of which memory blocks are served until
exhaustion
- if ActiveSheet has been used up, the Bucket continues with the next
Sheet that has free blocks;
if none is available, a new Sheet is created
A Sheet
- is a 16 kB..144 kB memory zone divided in BlockCount equal blocks with
size BlockSize
- memory blocks are served either linearly or from a single-linked list
of free blocks
- Sheets are allocated from from V-Blocks
A Memory Block
- 4 bytes overhead to store the Sheet to which the memory block belongs
- detects freeing an invalid block or twice the same memory block
A V-Block
- is a 256 kB..1024 kB zone of committed Virtual Memory (Windows)
- will be sub-divided into a number of Sheets
--------------
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Can someone please post the "FastMM4Options.inc" file (to attachments) with
options set for best performance and lowest memory usage in multithteaded
applications (no debug and memory leak information required), which one
could use when deploying applications?
I'd like to do more tests with FastMM4.
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Here is what I now have defined in the
"FastMM4Options.inc" file for deployment:
------------
{$define ASMVersion}
{$define Align16Bytes}
{$define UseCustomFixedSizeMoveRoutines}
{$define EnableMMX}
{$define AssumeMultiThreaded}
{$define HideMemoryLeakHintMessage}
{$define NoMessageBoxes}
{$define NeverUninstall}
-----------
Btw ... I also use FastMove.
Is there something I should add or remove?
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Hi Danijel,
I use memory manager from NexusDb
(www.nexusdb.com/showpage.asp I am very happy with it. Their
database product also contains this memory manager and three very well
written transport that might be of interest to you.
Regards.
Srini.
"Danijel Tkalcec [RTC]" <XXXX@XXXXX.COM>writes
Quote
I've just done a few tests using the standard Delphi memory manager,
FastMM4
and BucketMem_ASM. I was using Delphi 7 to compile my test apps and
running
the tests in a 100 MBit LAN with 14 Client PCs and one Server. Here are my
results (requests processed per second when using automatic encryption)
...

580 with the Standard Delphi MemMgr
1.310 with FastMM4 and FastMove
1.990 with BucketMem_ASM and FastMove

Each test was running at least 8 hours under full client and server load.

From this, I would say that BucketMem_ASM is a clear winner, but I haven't
used
it before (actually, didn't even know it existed a week ago), so I'm
wondering if someone has had more extensive experience using BucketMem or
some other third-party Memory manager and would be willing to share his
experiences here.


So, here are my questions ...

1) Which is your favourite Memory Manager?

2) Why do you preffer this one over the others?

3) How long are you using this Memory Manager?

4) Did you have any bad experience using it?


Thank you for sharing :)

Best Regards,
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm


 

Re: Memory Managers

Hi Srini,
What I read in their section about Threaded Memory Allocation sounds like a
dream come true (if they really can do what they are promissing):
"... If you now move your multi-threaded application to a multi-processor
machine, you will find that it might even run slower than on a single-cpu
machine. What you see is that the cpus are mostly running in kernel mode and
trying to get access to the critical code which typically is protected by
something like a critical section. The CPUs spend most of their time waiting
for this access.
Especially for server applications it is essential to maximize threaded
memory allocation. The NexusDB replacement memory manager uses a completely
different way to allocate/deallocate memory and minimizes these problems by
doing so."
Is there a Trial version of the Nexus Memory Manager?
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Quote
Is there a Trial version of the Nexus Memory Manager?
Yes they do.
www.nexusdb.com/showpage.asp
 

Re: Memory Managers

Sorry! the link should be
www.nexusdb.com/showpage.asp
Regards,
Srini.
"Srinivasan Iyer" <XXXX@XXXXX.COM>writes
Quote
>Is there a Trial version of the Nexus Memory Manager?
Yes they do.
www.nexusdb.com/showpage.asp


 

Re: Memory Managers

More info at the news.nexusdb.com groups. If you found the NDB MM worked
well for you, then a bunch of us will already have licenses, which would
take care of the source distribution problem.
 

Re: Memory Managers

Thanks!
I will be testing NexusDB MM and FastMM4 (using new options) with the RTC
SDK in the next few days and post my results to the RTC Forums:
www.deltasoft.hr/rtc/forum
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Danijel Tkalcec [RTC] schreef:
Quote
Is there something I should add or remove?
"AssumeMultiThreaded" is normally not needed, and will make any
non-threaded app suffer in performance.
The use of "Align16Bytes" is debatable, and rather wasteful of memory.
Danny
---
 

Re: Memory Managers

"Danijel Tkalcec [RTC]" writes:
Quote
580 with the Standard Delphi MemMgr
1.310 with FastMM4 and FastMove
1.990 with BucketMem_ASM and FastMove
Btw ... when changing the FastMM4 options file, I have noticed that "memory
corruption" and "leak detection" was activated. I guess, I have turned this on
see if there are some errors in the RTC SDK. This was good for checking if
there are bugs left in the RTC SDK, but it has added a lot of execution
overhead, which has reduced overall memory manager performance.
I will be doing new tests with FastMM4 in the next few days, which will then
be comparable to the result I received from BucketMem tests.
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Quote
"AssumeMultiThreaded" is normally not needed, and will make any
non-threaded app suffer in performance.
This is a multi-threaded app (Server using 260 threads).
Quote
The use of "Align16Bytes" is debatable, and rather wasteful of memory.
Ok, will turn this one off.
Thanks!
--
Danijel Tkalcec
www.deltasoft.hr/rtc/author.htm
 

Re: Memory Managers

Because you're seeing such a difference between FastMM4 and BucketMM it
seems like you've got an older version of FastMM4, or the extra debug stuff
is turned on. Out of all my testing and with the use of the fastcode MM B&V
tool FastMM4 comes out on top, sometimes just by 1-2%, but it always wins.
If you're code always shows FastMM4 lagging behind BucketMM then you've
probably got another good test case for the MM challenge.
Also the Fastcode project page has moved to www.fastcodeproject.org/
The latest FastMM is always at https://sourceforge.net/projects/fastmm
DD