Arnaud Bouchez

It is not obvious to me what is the advantage in respect to using an interface-based (or custom variant-base) instance holder. You can auto-generate the same try/finally hosting the data within an interface, or a custom variant. Since the oldest Delphi revisions. Interfaces can host regular objects with no problem. A custom record may be slightly faster, by allocating its memory on stack and not on heap - but performance is not the main point here, this is about code writability - less source lines, more hidden behavior.

Yes, GPL is known as a "viral licence": it infects with freedom any program using its source. Note there is a difference between GPL 2 and GPL 3 - the later being a bit more precise, and explicit about patent issues. https://www.ifross.org/en/what-difference-between-gplv2-and-gplv3 And that a library could also be published under LGPL, which is a version with "linking exception".

Indeed. I would have written an "out" parameter in the docs, at least. The function should set or initialize the value. And the compiler should emit a warning in your case. FPC is much more paranoid about such warnings, but at least it tries to warn anything dubious, and allow to disable false positives with the {$H-} trick on the faulty line.

I never install the Delphi 2007 IDE any more. I just copy the dcc.exe and some files (including its dcu) and use the command-line compiler. For testing, it was enough... and nothing to setup, just copy the files from an existing setup. Edit: But I understand now it won't help you, since I guess you need to validate installation of your IDE plug-in. Sorry.

This is the main point. Premature optimization is the root of all evil! 🙂 @Mahdi Safsafi Such abstract/broad input about non Delphi compilers has nothing to do with the initial question of this thread, which is performance of string process with Delphi. It is clearly out of scope and subject. What does a DSP compiler has in common with the Delphi compiler? Even the MAC units of DSPs have very little in common with regular CPUs.

You are right - initialize all objects in one go. My mistake. 🙂

So a REST server won't work since you need a COM object as Word Add-In.

@Mahdi Safsafi My experiment with the Delphi compiler and pointers is not the same as yours. In mORMot, I ended up with using pointers (PUTF8Char=^AnsiChar) for the raw UTF-8 processing, which generated faster code. Of course, pointers are difficult to deal with - you need to know what you are doing. I always consider pointers by looking at the generated ASM. If the code is better and runs faster with pointer, then I use them. Otherwise I don't. I am biased for sure: I like pascal because it can be both high-level and modern (like Java/C# - with high-level structures like classes, strings or dynamic arrays), and also system-level (like C). Pointers are clearly for the 2nd level. Anyone don't like pointers? Don't use them. But they are pretty convenient and efficient for low-level processing, if the goal is performance. I like very much when you paternize me with the Gather-scatter pattern. You can perfectly do Gather-scatter with two pointers. This is called pointer arithmetic - which I use extensively in mORMot. So I don't understand what you are talking about.

It occurred to Eric at least with DWS. He actually monitored it before fixing it. Of course, he dealt with a language compiler and execution stack, but I guess a lot of other kind of projects may have very tiny objects - if the SOLID principles are properly followed.

FastMM5 purpose is to shine with multi-threaded apps. For a single-threaded app, e.g. a simple RAD VCL/FMX project, performance may not be really better. Note: your benchmark function will probably spend most of its time not within the MM. I guess most of the time is spent in Memo1.Lines.Add if the search string occurs often.

Note that 32-bit and 64-bit COM servers are registered separated, IIRC. To communicate between apps, I would rather use a regular REST server. Our little mORMot can re-use an interface to define the service, just like with COM. Check https://medium.com/@step.bester/web-apis-with-mormot-891c0ecd3950

The cache line performance issue is still relevant. And it could happen in practice, e.g. when initialization in a raw. In mORMot, we used the filler to store some variants in https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_184

This is not as simple as this. IIRC prefecthing has no difference between indexed (mov ecx, byte ptr [eax+edx]) or direct access (mov ecx, byte ptr[eax]). The reference material about instruction latency and execution pipelinging is https://www.agner.org/optimize/instruction_tables.pdf and it is highly depending on the CPU. https://www.agner.org/optimize is worth reading and understanding. https://lemire.me/blog/ is another very interesting blog about performance of text processing, from a lot of experience and actual knowledge. Branchless SSE code will be the faster in all circumstances... Then use a wall clock measure of full realistic process - not just measuring a loop.

It depends on the complexity of the loop. For instance, about how variables are assigned to local stack variables or registers. If the use of the for-to index is not mapped into a register, then thatpointer[ i ] will be slower... Sometimes, just using a small local functions help the Delphi compiler make better register allocation, and may end up be faster... Remember 🙂

Branch prediction can do wonders in some micro-benchmarks, but they always have a cost, until the CPU logic actually "warmed up". No branch is always better, since the real problem is branch misprediction. Using the asm generated by a recent GCC with tuned optimization flags as a reference is a good hint of what is likely to be more efficient. Intel and AMD are major GCC contributors. And a wall clock of a realistic process (not micro benchmark) is the ultimate reference. We use some part of our automated tests as performance benchmark, running some close-to-the reality scenarios.

Indeed. This is why I use the "if x then repeat until not x" explicit pattern in time-critical loops of my framework - e.g. when processing JSON. As a nice side effect, the variables uses in "x" are more likely to be assigned to registers, since they will be used more often. Sometimes an explicit temporary local variable is needed. Or use of the 'result' variable if it is a PChar. Both Delphi and FPC require this, unless "x" is a single simple test, where I have seen FPC able to optimize it IIRC.

So Delphi would be a weird choice for programming. Regardless of how good it is, it's not widespread any more. The weirdest David's argument I have never read. Alternatives are good. Especially if they are better for simple projects. 😉

For a small and efficient Source Control Management system, even stand-alone with no server, you don't need git, tortoise and whatever... Just try https://fossil-scm.org/home/doc/trunk/www/index.wiki Only a 2MB download, for a full-bloated distributed SCM, with integrated web server, wiki and tickets. Perfect for any size of projects. It was made by the SQLite3 author, and I use it since years. Git was meant for Linux. Fossil was made for SQLite3. Ensure you read https://fossil-scm.org/home/doc/trunk/www/concepts.wiki and https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

I have written a blog article about this problem. https://blog.synopse.info/?post/2020/07/20/Special-Care-of-Delphi-10.4 Hope the issue is fixed soon in the next Delphi patch - after the holidays I guess. 🙂

This is the famous "patch release before holidays" syndrome... 🙂

I guess this bug may be some inheritance from DOS/TurboPascal years... when the 8087 was already there and no thread was involved.

Fair enough. 😞 But FPC doesn't suffer from this race condition AFAIK: procedure Set8087CW(cw:word); begin default8087cw:=cw; asm fnclex fldcw cw end; end;

I agree with you. IMHO it is less a breaking change than a bugfix. The behavior you propose seems more stable, in terms of thread-safety. Note that FPC RTL mimics the same behavior, and is affected by the same bug. Is just calling Set8087CW() at thread start enough as a workaround in user-code?

At first place, I don't understand how FreeAndNil() on an array pointer could work properly. It would try to call a Destroy method in the VMT, which doesn't exist... as @dummzeuch reported above. What you should do ASAP: 1. Get rid of all those FreeAndNil() on something else than class instances. 2. If you can , try to replace those pointer arrays with dynamic arrays, so you would have reference-counting and automatic free of the content when the variable comes out of scope. You can transtype a dynamic array into an array pointer just by using `pointer(aByteDynArray)`.

I don't know which size are your projects, but I used a 4GB Win10 computer until recently, with no memory issue at all. With hunderths of thousands of source code lines...