Why are the Delphi zlib and zip libraries so slow under 64 bit?

Question

Whilst benchmarking a real-world application I came across a surprising performance characteristic relating to the zlib and zip libraries that ship with Delphi.

My

Answer 1

As noted, the Delphi ZIP compression code stands on top of zlib. The Delphi implementation of zlib is a wrapper around the official zlib C source code. The C code is compiled to objects and then linked with {$LINK}. For XE7, the comments at the top of System.ZLib indicate that zlib 1.2.8 was used.

Under the obvious assumption that the time is being spent inside the zlib code, the most plausible explanation for the behaviour is that the 64 bit compiled objects are responsible for the poor performance. Either the compiler used is emitting weak code, or a poor choice of compiler options has been used.

So, I took the following steps:

1. I downloaded the source for zlib 1.2.8 and compiled with the Microsoft 64 bit compiler, cl.
2. Using the VS2010 compiler, version 16.00.30319.01. I compiled the objects with the following options: /O2 /GS-.
3. I then took a copy of System.ZLib.pas and included it in my project, alongside the newly compiled objects. This ensures that the newly compiled zlib objects are used.
4. I compiled the Delphi program with XE7 for 64 bit.

The run time, on the same machine as used to generate the data in the question was 6,912ms.

I then recompiled and omitted the /O2 option and went round the loop again. This time the run time was 20,077ms. So I hypothesise that Embarcadero have just been forgetting to compile these objects with optimisations.

I have reported this issue to Embarcadero's Quality Portal: https://quality.embarcadero.com/browse/RSP-9891

As mentioned in a comment below, it seems quite plausible that other libraries that rely on compiled objects may have similar problems. Potential problem areas include:

• MidasLib, objects are probably not performance critical.
• Indy, the version shipped with Delphi uses the same zlib objects I believe.
• System.RegularExpressions, a wrapper around PCRE.
• Vcl.Imaging.jpeg, built on top of a 3rd party JPEG implementation that is linked as compiled objects.

Update

The Quality Portal issue reports that this issue was fixed in XE8.