David Heffernan

That's not the same as starting from scratch. Also, didn't you have trouble with bugs in you asm code in your bigint library?

Well, that's exactly what I have been arguing for. It seems utterly insane to me that this task is handled at runtime when it can be handled at compile time. Anyway, as I understand it the record dtor would run in addition to the RTTI based finalization code. So adding a dtor could only ever make code slower.

True years ago, but these days not so. Just put some code through godbolt and marvel at the code that it generates. You don't have to get that complicated before you see the compiler spotting optimisations that are very far from obvious. Optimisers now have deep knowledge of hardware architecture and can use that to make choices that are beyond almost all human asm programmers.

That's because your button event handlers run busy message loops waiting for the child processes to finish. Your mistake is to run those busy loops in the main thread. You should consider running those loops in dedicated threads, and obviously remove the message processing. You code leaks the process handles and has other problems. Duplicating the code is a bad idea. You should be using CreateProcess to create processes. Fundamentally I would say that your main issue is that copying code without understanding it is a bad idea. You then become unable to maintain it and are unable to critique it.

Why would we want to finalize records manually? What a terrible retrograde step.

I don't much care what you like, or don't like. My point was that there exist plenty of compilers that can emit optimised code that is exceedingly efficient, and extremely hard to beat by humans writing code themselves.

You mean language rather than compiler.

Can I ask why you are interested in complexity of this algorithm? If it is for the sake of learning, fair enough, but there are far better examples to teach you. If it is for a real application, complexity is the wrong question to ask.

Very hard to find them though, and so easy to find good compilers.

Practical for small amounts of code that is seldom modified. Of course good compilers typically produce better code than humans can manage.

I'm not talking about the runtime. I'm talking about the code emitted by the compiler when it compiles my code. Performance is critical for my program. Some of the critical sections of code I translated to C in order to reap significant performance benefits of having a good optimising compiler. So yes, this is a real issue.

The complexity is linear with the number of digits. In this case it's probably much easier to write the code if you convert each number to text. You then need an array of counts for each digit. Count the digits. Finally check that each digit has the same number of occurrences. In practical terms, complexity arguments aren't actually going to be relevant here. It's the constant of proportionality that will matter most in performance.

I see pretty much the same code in 10.3 as produced by XE7 in my real world app, using the Windows x64 Delphi compiler. Performance is identical. Still significantly worse than could be achieved by the mainstream C++ compilers. Probably worse than what could be achieved in C#!

Runtime optimisation only helps if your code relies heavily on the runtime functions that have been improved. And where are these improvements in the code emitted by the compilers? I've not seen anything. What has changed?

It's more complex than that. Maybe for users of System.Generics.Collections. But what about those of us that write our own generic types?