Mike Torrettinni

Wow, even with Delphi 7 the results are the same! And it doesn't have FastMM at all! I don't have earlier versions to test, but I assume it's pretty much the same: Delphi cleans up the memory usage pretty good, even if you use really bad code with strings. As long as it doesn't crash (out of memory) string manipulation is pretty much safe and memory manager pretty much cleans up and releases memory back to the system.

No, no, it's refreshing to get a suggestion to read only what is relevant to the topic. I actually just read it! Usually I get suggestions to read whole books just for a simple question 🙂

Of course, because FastMM was integrated in D2006 already, so results are pretty much similar 😉 I thought it was in D2007.

Thank you for suggesting exactly what gives the relevant info, and not the whole book! 😉

I use arrays a lot, so of course also SetLength(array, length); after filing it, like this: // initialize array to fit all expected items + a little wiggle room SetLength(array, initial length + x); // current item index curr_index := 0; begin // fill in the array and increase index with each line // if curr_index (+1) > Length(array) : resize array to new length to fit more items Inc(curr_index); end; // finalize array SetLength(array, curr_index); I thought that I don't really need to SetLength, if it's already filled to the max: // finalize array, only if needed if curr_index <> Length(array) then SetLength(array, curr_index); So, I was looking into the DynArraySetLength to see what it does if you try to resize to the same length as it is. And DynArraySetLength checks for 0, <0, erros... but it doesn't check for NewLength = OldLength. This happens only a few calls later in ReallocMem -> GetMem -> AllocateLargeBlock. And it does some memory related stuff, but eventually doesn't resize or allocates new memory space. So it goes through all the memory stuff, instead of just simple check if we are resizing to the same size. Anybody using SetLength with condition? Does it make sense or not?

Interesting! I just ran the same example in D2006 and result is almost the same, at the end of the parsing the memory comes down to almost as it was at the start. Peak memory consumption is very similar, around 1.1GB. I don't have D7 installed to try.

Yes, when preparing this example I got carried away and I got 'out of memory' right away. So I had to scale back the bad example to work as intended 🙂

Thank you, but this wasteful, inefficient, slow and pretty much very bad example was done on purpose. I do not have such example in my code, but I do use MidStr, Delete, LeftStr... in some cases, so I wanted to see what happens in very bad example. I just wanted to test what the end result would be if you use such code. Seems like memory manager does pretty good job at the end.

I do use latest, full version of Fastmm, but am not changing any settings. Still from the times of D7 and D2006, and I never checked if it's still needed. It looks like what is integrated with Delphi works very well on it's own.

Aha, I see that Fastmm was integrated in Delphi in 2007(?), so I don't really need Fastmm in my projects with 10.2.3, I guess.

@Kas Ob. did you make any decision based on this 5+% wasted calls? You write it adds almost 8% extra connections, right? Do these increases make a deciding factors to make changes for you, or not? Will you implement the change in release version?

It's fascinating how many kids go through forced medication for false diagnosis. You, luckily, escaped it 🙂

Thanks! Pretty cool example with TStringList, will use it.

I use IfThen a lot. Delphi already has some of it's own IfThen defined: in System.Math are defined for numbers, in System.StrUtils there is one defined for string parameters: System.Math: function IfThen(AValue: Boolean; const ATrue: Integer; const AFalse: Integer = 0): Integer; overload; inline; //... and other number types of parameters System.StrUtils: function IfThen(AValue: Boolean; const ATrue: string; AFalse: string = ''): string; overload; inline; I have a few of my own, with XML types, TVirtualStringTree parameters... all overloaded of course, in my Utils.pas unit. I would like to have them all defined in my Utils, so I only need to put Utils in uses. The problem is when if I still need to use System.StrUtils or System.Math for other functions, I get error: E2251 Ambiguous overloaded call to 'IfThen' System.StrUtils.pas(499)... It makes sense, because same Ifthen signatures are not in System.StrUtils and my Utils. Is there anyway to avoid this error and force it to use IfThen from my Utils and not get this error?

Just looking for some ideas how to prefix unit's local variables. In last few years I got used to these prefixes: TVarType; (I just can't get used to lower case: tVarType) fVarName - local field gVarName - global var vVarName - method local var aParam - parameter cConstName - constant unit local var: I used to have LVarName, then lVarName, now I have: xVarName, which I like, but looking for other ideas.

@Dany Marmur Did you discover what was the cause of the slow loading time? What tools did you use? Any interesting discoveries? I'm interested in anything useful that I could apply to my projects, if applicable, of course.

Some forums allow edit old posts and adding additional updates, some posts are relevant throughout the longer period of time and would be nice to just add an update when needed, instead of starting new thread. Of course when updating old post you add something like Update on xx/xx/xxxx: ... and you have 1 long post with useful info in one place.

Thank you! Bikeshedding is a metaphor to illustrate the strange tendency we have to spend excessive time on trivial matters, often glossing over important ones. I need to keep some of my own personal quirks even in coding... if that means my prefixes are trivial and waste of time... if that means I will never be Delphi expert... if that means I annoy someone on the internet... too bad, I like them! 😉

Now reading comments again it's good to know we all customize to some extent, to fit the purpose. As most of the time I'm the only one on the team, I can customize prefixes as I want to. I think KebabCase ( kebab-case ) wins the naming war 😉

I would file it if I had a case where the changes would have meaningful effect, but I don't have one. Maybe it's better not to waste their time on this.

I see now where you were going, no, this case is not about performance. It was more curiosity, will it copy to new memory space, will it just do nothing or something else. I would expect a check and exit. I don't know a lot how memory works, so looking at DynArraySetLength was pretty interesting and not that much complicated, so the missing check was pretty obvious.

I can't classify it as defect, is more a wish that it wouldn't do all sorts of calls, runs through asm code, Delphi code... just to end up with the same result as it began with. I wish I didn't go and check... 🙂

🙂 It never ends well when you ask 2 questions in a row - usually means I'm way over my head. I have no idea what answer are you looking for that would make sense to you, so I can only answer with something like this: the difference would be that the missing check would not be missing anymore.

At a quick glance it seems DynArraySetLength could use a simple check before trying to set size which is the same as original. This way it would avoid additional checking and calls, which at the end do nothing or result in the same size as before. The method has a check if newLength <= 0 and Exit if True, it could have similar check if newLength = oldLength and Exit if True. Of course I could be completely off here.

Very good point, I rarely use dynamic multidimensional arrays, so I didn't consider this. If DynArraySetLength had this simple check, it would be so much easier - I would ignore and never come back to this question 🙂