[DUG] D2007 to XE2 conversion notes

[Jolyon Smith]

> On the other hand - it looks like the same test program uses a lot less
> memory than the old D2007 version.    The figures vary wildly depending on

John, none of the utilities for measuring "memory use" are actually
reporting truly "used" memory.  The only thing that can do that is some
utility which can interpret the information in the process heap and work
out which memory is actually in use by the process and which memory has
been allocated just in case it may need to be used.

The efficiency of those heap structures comes down to the memory management
within the process itself.

Both D2007 and XE2 employ the FastMM memory manager, but I seem to recall
some changes in FastMM since D2007 that will therefore affect how XE2
manages it's heap differently from FastMM in D2007.  In particular I have a
hazy recollection of some change in the way that FastMM manages allocations
of different sizes.  Internally there are/were essentially separate heaps
for small, medium and large allocations - or something along those lines.
 I think one of the changes was the threshold levels by which "small",
"medium" and "large" are determined (or possibly even further separate
heaps).

If an application has a large number of allocations at or around one of
those thresholds, then it's conceivable that the apparent memory usage of
the app will appear to change as those allocations are transferred from one
heap (in an earlier version of FastMM) to another with a different
management strategy.

e.g. (and this is a fictional example for illustrative purposes, not
necessarily describing FastMM accurately)

If the medium heap is managed with the expectation that smaller medium
sized allocations will expand into larger blocks, then the memory manager
may pre-allocate a larger block as a "minimum" for any medium sized
allocation, where-as a small allocation may be allocated precisely.

Let's say the medium block threshold is 256 bytes with a 512 byte minimum
allocation.  If you have a lot  of "medium" allocations of 300 bytes but
which - despite the expectations of the memory manager - never "expand",
then those will result in 512 bytes per allocation and a "waste" of 212
bytes in each case.  If the threshold for "medium" allocations is then
raised to 384 bytes, suddenly each of those 300 byte allocations fall into
the "small" heap and are allocated exactly.  The memory manager is no
longer "wasting" 212 bytes on each allocation.

With 1000 such allocations in an app, what you will appear to see in Task
Manager etc is that your app now uses over 200K less memory.


The finer points of heap management are a complex area.  FastMM itself was
a step change from the previous memory manager in Delphi, and it's not
surprising that FastMM itself continues to evolve.

Like I say, this isn't necessarily exactly what happened in your case, but
no doubt what you are seeing is the result of changes in FastMM, of which
the above is just a speculative, illustrative example.

You would probably see a less dramatic difference if you were to use the
same version of FastMM explicitly in each case, rather than using the
version "built in" to each version of the RTL.

hth


Happy New Year.  :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://listserver.123.net.nz/pipermail/delphi/attachments/20120117/be3589ea/attachment.html