Stefan Glienke

Yeah, sure...

It is as relevant, if not more (there are other results further down the article from other sources) than one person telling me how well AI worked for them. This entire "I need a dedicated sub forum for AI to discuss AI" debate is getting ridiculous - if you have something to share, then do so. If we find out that one or multiple sub forums are containing loads of threads about a certain topic, a mod might create a new sub and move them there - easy as that.

https://fortune.com/2025/07/20/ai-hampers-productivity-software-developers-productivity-study/

I haven't found a critical regression in the past 24 hours.

Wasting terajoules for basic refactorings, welcome to 2025

In my opinion, creating new forums should only be considered if there is sufficient activity around this topic (regardless of whether it's AI or anything else), which I don't currently see.

I would assume that both products are from you, though? Then why not make both use a shared package that contains that shared global state?

This is exactly what I explained back in 2024 in this very thread

As much as I did, I assume

You are missing passing TFormatSettings to the StrTo... functions that you are calling - that makes it fail on systems that use a comma as a decimal separator, for example.

Fair enough - however, either only TStringList would have these methods, or they would need to be virtual in TStrings with an unoptimized loop implementation in any inheriting class that desires. FWIW, one of the AddStrings overloads is virtual, but TStringList still does a loop calling InsertItem. Why does it do that? Because InsertItem is also virtual, and any inheriting class can do whatever it wants in there. Providing any non-looping operations would possibly circumvent any custom logic that sits in such an override.

Yes, it solves your problem - but in the context of this thread, this is just a terrible hack - if you add a new case, you have to change not just one place but several ones and make sure you did not make any mistake with the index or the order.

InsertRange and DeleteRange, as you describe them, are not possible without changing the existing TStringList behavior regarding OnChanging/OnChange - currently, if you insert or remove several items in a loop using Insert or Delete, on every OnChanging/OnChange call, the TStringList has the exact Count and Items before/after that one insertion/deletion. With a bulk insert or deletion, that would not be the case. Also, fwiw, the adapter in Spring is to wrap an existing TStrings as an IList<string> if some API requires - not to make TStringList any more performant. Regardless of all the nifty features of TStringList for most string-only operations that need to be super performant, I would rather avoid using it because its internal storage layout is terribly wasteful (i.e., storing those string/object pairs). Also, that adapter is for TStrings and not just for TStringList.

With a fixed set of strings to look up, hashing is never the fastest way, but a handcrafted way. Let's, for example, imagine a case statement that checks for all keywords in the Pascal language. Arrange the strings in the lookup table by length and first letter. You can see how the C# compiler does it - I wrote a simple demo with just a few keywords: https://sharplab.io/#gist:731036823c89363962d7e79f9dc9ed28 There is a lot of material you can read on that subject: it is called "switch lowering"

The call stacks are bogus - some entries below WideFormatBuf is incorrect - System.LocaleCharsFromUnicode never calls System.SysUtils.WideFormatBuf - but FormatBuf does. Then some entries below DateTimeToString are incorrect - it most likely was called from TryEncodeTime