Re: Memory Manager Test Results
- From: "Danijel Tkalcec [RTC]" <dtkalcec@xxxxxxxxxxx>
- Date: Thu, 22 Dec 2005 18:14:00 +0100
"Pierre le Riche" wrote:
> Some further points I would like to make:
> 1) Your benchmark reserves a lot of address space (the light gray
> squares), and not through the memory manager. If you look at the FastMM
> screenshot, the pink strips are blocks allocated through FastMM. All the
> rest is allocated through other means. I don't know what in the benchmark
> is reserving that address space and for what reason, but it doesn't make
> address space usage comparisons using this benchmark very useful.
I don't know what could be allocating memory directly through Win API, since
I don't use API calls at all for memory allocation (using GetMem/FreeMem and
standard constructors/destructors for objects). The only part of code which
isn't under my direct control is the zLib library. But, I doubt that zLib is
directly using Win API for their memory needs and it also looks like you
didn't activate compression in your test.
Do you have an idea what could be reserving memory (the gray blocks) if it
isn't my application code?
> 2) Memory usage varies wildly between runs. Sometimes the address space
> usage is about 160MB, sometimes it goes up over 250MB with FastMM as well
> as with NexusMM. The memory allocated through FastMM or NexusMM stays more
> or less constant at 47MB, but the benchmark reserves wildly varying
> amounts of address space during each run. Another reason why address space
> usage comparisons using this benchmark is not useful.
I don't understand this point. In multithreaded apps, there are a number of
threads running, each allocating and deallocating memory space. It is not
predictable what will happen, but if you let the test running for longer,
you will get average memory needs.
> I haven't done any speed tests yet. I'll give that a go a bit later. Most
> important for me was to figure out what was going on with the address
> space measurements, and I think I have now disproved any claims that
> FastMM fragments badly or wastes memory (at least in this benchmark)...
> 97.5% address space usage efficiency is perfectly acceptable IMO.
Btw ... in your test, you didn't activate compression on the Server. I don't
see the client-side in your screenshots, but if you used default settings,
then compression isn't activated there either.
When using automatic compression, compared to no compression, default RTL MM
performs 5 times better (570 requests per second vs. 106 requests per
second), so please activate it for your tests.