Re: Memory Manager Test Results

"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.

Danijel Tkalcec


Relevant Pages

  • GC performance - GC fragility
    ... As a followup to the GC perf thread, I posted a small tweak of the benchmark in the attachments, to illustrate how wrong and how easily things can go with a GC (and how tricky benchmarking memory managers outside of real-world applications is). ... Basicly the original test was allocating an object with single TStringList field, and added a single short string before "releasing" the whole. ... Sean, this is an example why a GC can be considered "hideously" slow: its execution complexity isn't constant (unlike FastMM), and the more you stress it, the less efficient it becomes at managing memory. ...
  • Re: Processor Performance Ratios?
    ... Note the second Core i7 score is worse than my system, while the first score is not much better--why? ... I have 4 MB memory. ... Processor cache. ... benchmark of 1M should run real good there. ...
  • Re: MM chalange
    ... > Currently I am creating a new memory manager that is build only for speed ... To have that kind of speed advantage in a benchmark I guesstimate you have ... > some time for testing / tuning but am willing to donate it to the fastcode ... > 1) How can I donate the code? ...
  • Re: Fastcode - Alternative SZ IntToStrB&V v0.09
    ... Be aware that data need to fit in phisical memory during ... Preparing space to store report data before stat of benchmark to ... > avoid problem with fragmentation ...
  • Re: New replay benchmark : XML Parser
    ... one does get some noticeable speed and memory ... I suggest we include this benchmark in the B&V0.35 tool. ... > and BucketMem (1200 for RecyclerMM) ... > Not sure if it's the file loading time ...