David Heffernan

You missed step 1. Step 1: identify the bottleneck. It's a common mistake.

All this incredible noise, and all Mike needs is to simply time his own program...... It's really so simple.....

I don't really buy what Kas is saying above. Just time your actual program is usage scenarios that you care about. After all, why would care about the performance of code that you never run? You only care about the code that you do run, or your users run.

Because timing a for loop doing 1,000,000,000 iterations of nothing meaningful is nothing more than a low grade PRNG. Put something realistic inside the loop, and then time it.

It isn't. Hmm .....

Well, it's reasonable to wonder about that, and Stefan talked about that. But you actually spent a lot of time talking not about the codegen, but about performance. And the key point is that there is no performance difference for the two versions of the code that you presented, once you put the code in a context where it actually does something. After all, the code you showed doesn't initialise any variables, and just performs the exact same two comparisons on each iteration of the loop. Here's a question for you, why don't you compare the run time of your code, with code where your for loop is removed? I bet it will be faster with the for loop removed. And the code does the same thing with or without the for loop. Obviously that's silly because the for loop is meant to represent some real world code. But it's only meaningful in the context of actual production code. I've said it many times, but when you put your two variants into your real world program, you won't be able to tell them apart from the perspective of performance.

Can I ask again why you are timing something that has no relevance to the performance of the code that you care about? Once you time these variants in a real program, you will find that you won't be able to detect any difference in runtime. And then you will draw the conclusion that the best way to write the code is in a manner which avoids duplication of code, and which makes it easy to maintain. You'll likely also decide that there is no real gain in explicit inlining of the function here, and will stop doing that.

Records can be managed types

That's not the conclusion of this topic.

Why are you doing this? Have you timed your actual program yet? Do the two options perform measurably differently? Is that code even a bottleneck?

This test seems pointless because the two strings are always empty. You never read the strings from a collection. You never compare two strings. When you put this code into a realistic setting you'll likely find that it makes no difference to performance which versions you use. The smells of premature optimisation. And that results in hard to maintain code.

Show the code that raises exceptions that you think are a sign of poor design. Details matter.

Can you show the code?

The RTL and spring4d are actually pretty comparable. Your claim that spring4d code should only raise a single exception class indicates that you don't appreciate its scope. Im an advocate for understanding something before judging it.

Ask yourself why the RTL raises more than a single class of exception.

Andreas is presumably doing other things these days.

Casting to a helper should never be supported. That's just ugly. May as well call a function and be done with it. You lose all the benefit of type extension if you have to cast.

The decision to implement the collections as records look problematic to me. That means these types will have value type semantics.

Inheritance would not be the ideal solution. That would make it impossible for two distinct libraries to extend the same type. I don't understand what is hard about having multiple helpers active and searching through them, most recently declared first.

We all think that ...... C# extension methods allow types to be extended from multiple classes .....

Nope. This is an endeavour that is doomed to fail. You'd have to duplicate the implementation of the standard helper if you wanted to have access to its functionality as well as that in your own helper. It's been this way since helpers were added, and I have given up hoping that the issue will be addressed.

Would be nice to localise the disabling of overflow checks to just the hashing routines.

Sure. But there has never been a compiler bug where this particular language contract was not respected. You say that you have seen the compiler generate code which evaluates for loop ranges more than once. But that's incorrect. You have not seen that because no version of Delphi has ever had such a bug. My point is that it is poor advice, a canonical example of FUD. For sure it's worth knowing that while loops are different. Proficient Delphi programmers do know this, and are alive to this whenever they make choices of which loop to use.

You have not seen this. The classic for loop evaluates the loop ranges exactly once. This is contracted by the language. http://docwiki.embarcadero.com/RADStudio/Sydney/en/Declarations_and_Statements_(Delphi)#For_Statements "For purposes of controlling the execution of the loop, the expressions initialValue and finalValue are evaluated only once, before the loop begins." This sort of FUD is not helpful to anybody.

There were two points in that post. The point about not using Length of the internal list is well made. But my post reacts to the other point in that post which advocated taking a copy of Count into a local variable before the for loop.