Does Delphi XE produce faster code than Delphi 2007?

Question

I've been using mostly Delphi 2007 for projects that don't need Unicode.

Lately I've been wondering about Delphi XE because

• everybody is praising it;
• build-in SVN support

I was wondering though, have there been any enhancements in the compiler that make Delphi XE to produce faster code than Delphi 2007, I'm talking about things like:

• better elimination of dead code (delphi 2007 is decent, but does not eliminate 100% of dead code)
• loop unrolling (ala C's O3 optimization level)
• auto inlining of short routines
• less overhead in multithreaded code.

EDIT

On this page: http://www.embarcadero.com/products/delphi/whats-new

It lists: Improved compiler performance So what exactly is improved?

Answer 1

Two points, for my two cents:

1. For our Open Source ORM framework

When running our unit tests with Delphi 7, Delphi 2007 and Delphi 2010 compilers, I found out some speed improvement between Delphi 7 and Delphi 2007, but not noticeable between Delphi 2007 and 2010. Delphi 2010 generated code was found out to be even a bit slower. I don't have a Delphi XE compiler at hand, but I guess it's somewhat the same as Delphi 2010 - mainly bug fixing about generics, AFAIR.

I spent a lot of time in the asm view (Alt-F2) when I write low-level pascal code, and use a profiler. So I usually notice difference between Delphi compiler versions.

IMHO the main improvement was indeed the inline keyword for methods and functions/procedures, available in Delphi 2007 and not in Delphi 7. Another improvement was a more aggressive register re-use.

Floating-point generated code is still slow and sometimes awfull (the FWAIT is still produced, even if not necessary any more, and inlining floating-point code could be even worse than with no inlining!

What is interesting about our framework, and all those tests is that it does process a lot of data, using its own low-level units, coded in very tuned pascal for best performance. And the unit tests provided (more than 5,400,000 individual tests) work on real data (numerical conversion or UTF-8 text processing), with a lot of diverse processes, including low-level conversions, text parsing, object allocations, multi-threading and Client/Server orientation. So here, the code generation by the compiler does make a difference.

The code is mainly inside our framework. We use our own RawUTF8 string type, and not the generic string. Therefore, the bottleneck is not the VCL nor the Windows API, but only pure Delphi compiled code. In fact, we avoid most API calls, even for UTF-8 encoding or numerical conversions.

Of course, I tried this benchmark with PUREPASCAL conditional set, i.e. not running the optimized part in asm, but rely on only "pure pascal" code.

2. For SynLZ compression unit

Another good experiment about speed was writing and profiling our SynLZ compression unit. With this optimized implementation of the LZ compression algorithm, compression is 20 times faster than zip, decompression 3 times faster. In fact, it competes with LZO for compression ratio and decompression speed, but is much faster than LZO for compression: SynLZ is able to compress the data at the same rate than it decompresses it. Such a symmetrical implementation is very rare in the compression world.

It involves only integer arithmetic and bit logic, filling and lookup in hash tables, and memory copy.

We wrote some very tuned pascal code, then compiled it with Delphi 7 and Delphi 2009.

The Delphi 2009 generated code was faster than Delphi 7, in a noticeable way. Generated code was indeed better, with better register reuse.

With hand-tuned assembler profiling, we achieved even better performance. For instance, a 6 KB XML file is compressed at 14 MB/s using zip, 185 MB/s using LZO, 184 MB/s using the Delphi 2009 pascal version of SynLZ, and 256 MB/s with our final tuned asm version of SynLZ.

Conclusion:

For the generation of code involving integer process, text parsing or memory , I think Delphi XE is faster than Delphi 7, but should be more or less at the same level than Delphi 2007. Inlining was the main new feature, which could speed up a lot the code.

But for real-world application, speed increase won't be noticeable. About 10 or 20% in some specific cases, not more. Algorithms is always the key to better performance. Delphi 7 was already a nice compiler.

For floating-point arithmetic, the Delphi compiler is nowadays deprecated. I hope that SSE code in 64 bit compiler will change the results here.

To answer directly your question, in Delphi 2010 or XE, there is no auto-inlining nor auto-loop-unrolling, AFAIK. And overhead in multi-threaded code is not part of the compiler, but on the library (FastMM4, reference counting and such). So I don't think Delphi XE produce faster code than Delphi 2007.

Answer 2

My informal testing of the Delphi XE compiler shows that the code generation is noticeably more correct in many cases involving the use of Generics, and that certain compiler internal failures (bugs) that had dogged the compiler in the Delphi 2009, 2010 era, are now fixed. In many cases, Delphi 2010 code using generics, linked into packages, when rebuilt repeatedly in the IDE, would result in corrupt DCP file output, or mysterious compiler internal errors, during compile and link.

I would have written in the release notes, if it was me, "we fixed the bugs". (I retract the "Best Ever" phrase, because it seems people think I meant it as advertisement for my then-employer, I formerly worked for Embarcadero). I suppose that all of that has been smoothed over into the word "performance", where performance is understood as "correctness", and "doing its job reliably, and without glitches".

As for speed, I have not noticed any statistically significant difference in profiling code from Delphi 2009, 2010, or XE, as far as its performance-at-runtime speed, nor the compiler's performance, in terms of "it builds projects faster".

Since you asked about Delphi 2007, you should be aware that there is a huge type change (String=AnsiString, to String=UnicodeString). For the same code, some things will be slower, and some things will be faster, and it's 100% impossible to say what will happen if you recompile your 2007 code in 2010, without knowing lots about your code. If you relied heavily on WideString before, and you can now use UnicodeString instead, your code will get much faster since UnicodeString performance is much better than WideString performance. Some delphi programs spend a lot of time in your code quietly (and nearly invisibly) converting your ansi data up to unicode data, internally in win32 , such as when you use a Memo common control. On the other hand, some things that used to use byte-size strings, will now be using word-size strings, so memory usage will increase in some places, and some operations may get slower. The most likely net result, for properly ported code (you have to make some changes to most applications to get them to build in XE, if you wrote them for 2007) is, if anything, a tiny net decrease in "raw performance".

However, Delphi XE builds projects, and more importantly rebuilds and rebuilds, over and over in the IDE, without incident, and never crashes on me. Delphi 2007 crashed on me all the time. Delphi 2007 also has hundreds of annoying compiler bugs that would drive me crazy. Compiled-code-speed is not even the main reason to upgrade, reliability is.

Often in large projects I have been using, Delphi 2007, 2009, and 2010 would crash on the second or third rebuild of some complex set of packages. In 2009 and 2010, packages that made heavy use of generics were especially likely to crash the IDE. XE is stable, even when I use it with heavy generics code, and that is a kind of "performance" improvement that the release notes might be talking about. I call it "bug fixes".Let's call a spade a spade.

(Deleted last paragraph, because people thought it was an advertisement)

Answer 3

I don't see any evidence of any significant improvements on code generation. I'm not aware that there has been anything very significant in terms of code generation improvements since Delphi 5. In fact I've never found my code running faster following an upgrade and that's stretching back to Delphi 2.