Leaderboard

There is a short explanation to the FastMM internals in Mastering Delphi Programming: A Complete Reference Guide (https://www.packtpub.com/product/mastering-delphi-programming-a-complete-reference-guide/9781838989118). Along many other good stuff. The PDF version is very cheap. Really worthwhile,

And I guess, you are expecting something from us, we can't deliver. Yes. It's even better. In the case "very well" and "even better" are SI units.

What's the point? You've already reached a false conclusion based on a flawed investigation. If we try to point this out you tell us that you aren't interested in learning the truth.

Sometimes, before I can make my decision in a particular matter (not programming) I do google/read/watch/test for days or for a week or once in a time even longer. If you would use the time for the same instead of this kind of nonsense topics, you would have more of it. We too.

You test is a synthetic benchmark of metrics you don't understand yeilding results you don't know how to interpret. As usual this is completely pointless. I see you've highlighted the peak working set size but do you even know and understand what a working set is? If you really want to learn about how different memory management challenges can affect you then start by learning about what those problems are. Make an effort. One of the reason why your benchmark isn't doing as bad as you'd expect is probable the lack of randomness in the test. You're repeating the same pattern 100 times. If your allocation were random this would fragment the heap badly but since you're allocating, freeing and then later reallocating the same block sizes again and again, there's good likelihood that the blocks can be reused.

No, but doesn't windows handle the released memory quite efficiently? The memory consumption from just this test is 10GB+ and system has no less available memory after the test is done.

Actually, your code is wrong. Now you are doubling the memory usage. SetLength creates a big string, then in the loop, you add more to it... If you wish to pre-allocate the length of the string, then you need to do it this way: Function MultiplyStrWithPreallocate(aStr: String; aMultiplier: Integer): String; Var i, pos: Integer; Begin SetLength(Result, Length(aStr) * aMultiplier); pos := 1; For i := 1 To aMultiplier Do Begin move(aStr[1], Result[pos], Length(aStr) * sizeOf(Char)); Inc(pos, Length(aStr)); End; End; Here is what is going on behind the scene, when you call: Result := Result + aStr; the memory manager creates a new temporary string, assigns the content of "result" and "aStr" to it. That new temporary Strings is then assigned to "result" which in turn decreases the reference counter to the String that result is refering... in that case to 0, which causes the memory manager to release that String. So for a short period of time, both, the original "result" and the "result"+"aStr" are in memory. And for each for-loop-iteration, you basically have a copy operation of the whole string. My above optimization using move reduces both of those concerns. There is just one memory allocation, and only a few bytes are copied in each for-loop-iteration

TStringHelper.Compare has an overload where you can give the option TCompareOption.coDigitAsNumbers for this purpose.