> On the other hand - it looks like the same test program uses a lot less<br>> memory than the old D2007 version. The figures vary wildly depending on<br><br><div>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.<div>
<br></div><div>The efficiency of those heap structures comes down to the memory management within the process itself.</div><div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>e.g. (and this is a fictional example for illustrative purposes, not necessarily describing FastMM accurately)</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>hth</div></div><div><br></div><div><br></div><div>Happy New Year. :)</div>