Stefan Glienke

If it is currency, then FloatToStr is wrong to begin with

The big performance gain did not happen between 11 and 12, but between 10.2 and 10.3 Additionally, JDO does not leak any memory; it simply does not deallocate when calling TJsonObject.Clear

lol I wish

No compiler optimization on earth is helping you when core RTL functions do heap allocations all over the place for things that don't require them at all - just an example. Additionally, even in C++, which arguably has some of the most advanced compilers to date, some of the core runtime functions are written in hand-tuned, platform-dependent assembly.

So did I. I refrain from projects in which the initiator themself does not contribute anything.

Man, that UltraCode project really took off in the past 6 years, didn't it?

I figured as much - I just mentioned this because if you look into how it is done, you will find one of two typical implementations of how you can count occurrences: One being similar to how you would do it in real life: once you find the first occurrence, you add it to your notepad, and after that, you just increase its counter - typically this is being done with a hashtable The second one is sorting the input because then you don't need to maintain a hashtable for count lookup, but you know that all occurrences are adjacent to each other.

Just fyi: counting occurrences of approx 40k 5-character-long strings takes about 1ms with a Spring4d multiset and is a one-liner.

Forget about GetTickCount(64) when doing any performance measuring - just use TStopwatch from System.Diagnostics.

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

No