Olaf Monien’s blog.
Maybe @EivindB might have some insight?
I read that article - whilst he is not wrong about the issues - the article is painfully verbose ai slop.
TLDR; FireDAC is slower than dotnet.
Wow, that’s certainly a nasty surprise!
Alex
- Olaf Monien’s blog.
I wouldn’t have thought that sounds like Olaf …
When I pasted the URL, I wondered if it had been written in German. Could it be a translation?
I know Olaf pretty well, we worked together back in the day (20+ years ago when Chad Hower and I were business partners).. his english is very good (and he could drink me under the table easily).
He has gone all in with AI and that article reads very ai’ish to me - I found it very difficult to read.
I came across a youtube video that said to avoid AI slope English, use a scientific English standard initially created in the 1980’s.
The standard includes:
- Restricted vocabulary: Approximately 900 approved general-purpose words.
- One word, one meaning: Avoid synonyms and words with multiple interpretations.
- Short sentences: Keep instructions concise.
- Active voice: Prefer “Turn the switch” over “The switch must be turned.”
- Consistent terminology: Always use the same term for the same component or action.
- Simple grammar: Avoid unnecessarily complex sentence structures.
- Clear instructions: Write procedures that cannot easily be misunderstood.
Here is what ChatGPT suggested as a prompt.
Write using the principles of ASD-STE100 Simplified Technical English, but do not strictly restrict vocabulary. Prefer plain, direct English. Use precise terminology, short sentences where appropriate, and concrete explanations. Avoid unnecessary adjectives, promotional language, repetitive sentence structures, stock AI phrases and excessive formatting. Vary sentence length naturally. Do not sacrifice technical accuracy for simplicity.
I also know Olaf very well and I concur, he speaks, and writes, excellent English. This article is definitely heavily AI derived.
It would also have been helpful if, given the excellent relations he and the company have, he could have presented the article to us so we could have commented on it and also see if we could have included the issues he raised in an upcoming patch or minor release.
The first we knew of the issues was when the article was released which corresponded with the bug reports.
Now we have an article which stinks of AI and effectively a zero-day fix.
It also seems to serve the purpose of self-aggrandizement rather than identifying an issue and letting Embarcadero have the opportunity to fix it and taken in isolation, could very likely result in decision-makers using it as a “see, we should definitely use .Net for everything”. The last thing we need is to feed the sharks.
The speed difference is our (Embarcadero’s) problem to fix - no excuses - and what he’s raised is obviously something we want to address ASAP if he’s included suggested fixes/improvements.
Of course, he’s not required to run it past us, for lots of reasons, but god knows I spend a lot of time trying to improve things for community, the quality of the product, and the public perception people have of Delphi and all that goes with it. Simply reaching out to us, me, or indeed anyone, by a well-respected MVP is of course going to be taken very seriously, especially when the problem is well-defined, and even has suggestions of how it can be mitigated.
I am extremely disappointed that we couldn’t have worked to have a more positive discovery, rectification, and revelation process that could have been one of MVP finds an area where we could improve our chances against .Net and, together, could have had him write about this as a “I found a speed issue for FireDAC and Embarcadero and I got it fixed and now it rocks!”
To reiterate, he’s done nothing wrong, per se, good on him for finding the problem, but this could have been approached from a different perspective.
To me, the biggest problem in the article wasn’t DB performance or the lack of it, but the fact that Olaf found it necessary to write his own profiler to get the results. 
As an MVP he should have talked to us in NexusDB to get a copy of Nexus Quality Suite, which is currently in advanced v2 beta stage.
So, here’s what we will do:
To assist with chasing down performance improvements for the good of all users, we have decided to provide Embarcadero with a perpetual Site license of Nexus Quality Suite. We hope it will be put to good use!
Writing a sampling profiller using claude is pretty easy - I created my own (command line only) - specifically to use with ai - I know @Geoff created one too - probably for the same reason.
Of course I also used NQS to get down into the weeds when chasing peformance issues.
I thought AI was clever when I got it to sprinkle timing statements throughout the code… It did a pretty good job of speeding things up, but involved adding statements to the code and then removing them. With the sampling profiler, it was able to do very similar performance improvements without the need of adding those extra statements in.
One issue I had was with TFormatSettings.Invariant - which is very slow if called repeatedly. The profiler picked up the problem… in the code it had written and then fixed it within a couple of minutes (solution is to cache the record). This knocked seconds off some operations, going from feeling slow to making the operation being an acceptable speed.
And then there are those that remember the days of ‘Turbo Profiler’ and wonder why support for it was dropped.
I wonder if AI used the old source to build up it’s current knowledge?
So much ‘What’s old is new again’.
Last week I was performance profiling a financial Monte Carlo simulation in one of our Delphi apps using VTune. It’s a set of complex calculations and conditions that has already been thoroughly manually optimised to avoid data lookups, recalculating values, loop nesting order, etc. What surprised me was that the most time consuming single function call was System.Math.IsNaN (a lot), which internally uses a Double record helper to get the flags/status of the value. I shaved off 20%! of the total simulation execution time by replacing IsNaN with a single line bitwise test optimised for the resulting assembly in an inlined function. Without a profiler I would never have guessed this to be a problem.