为什么Delphi zlib和zip库在64位以下如此缓慢？

Question

在对实际应用程序进行基准测试时，我遇到了一个与Delphi附带的zlib和zip库相关的令人惊讶的性能特性。

program zlib_perf;

{$APPTYPE CONSOLE}

uses
  System.SysUtils, System.Classes, System.Diagnostics, System.Zip;

const
  LoremIpsum =
    'Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod '+
    'tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, '+
    'quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo '+
    'consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse '+
    'cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat '+
    'non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.';

function GetTestStream: TStream;
var
  Bytes: TBytes;
begin
  Result := TMemoryStream.Create;
  // fill the stream with 500MB of lorem ipsum
  Bytes := TEncoding.UTF8.GetBytes(LoremIpsum);
  while Result.Size < 500*1024*1024 do
    Result.WriteBuffer(Pointer(Bytes)^, Length(Bytes));
end;

procedure DoTest;
var
  DataStream, ZipStream: TStream;
  Stopwatch: TStopwatch;
  Zip: TZipFile;
begin
  DataStream := GetTestStream;
  try
    ZipStream := TMemoryStream.Create;
    try
      Zip := TZipFile.Create;
      try
        Zip.Open(ZipStream, zmWrite);

        Stopwatch := TStopwatch.StartNew;
        DataStream.Position := 0;
        Zip.Add(DataStream, 'foo');
        Writeln(Stopwatch.ElapsedMilliseconds);
      finally
        Zip.Free;
      end;
    finally
      ZipStream.Free;
    end;
  finally
    DataStream.Free;
  end;
end;

begin
  DoTest;
end.

Compiler  Target  Time (ms)
     XE2   Win32       8586
     XE2   Win64      18908
     XE7   Win32       8583
     XE7   Win64      19304

我使用Explorer shell ZIP功能压缩了同一个文件，我粗略的秒表计时是8秒，所以上面的32位时间似乎是合理的。

由于上面代码使用的压缩算法是zlib（Delphi的邮政编码只支持store和deflate)，所以我的信念是Delphi使用的zlib库才是这个问题的根源。为什么delphi的zlib库在64位以下这么慢？

Answer 1

如前所述，Delphi ZIP压缩代码位于zlib之上。zlib的Delphi实现是围绕官方zlib C源代码的包装器。C代码被编译为对象，然后与{$link}链接。对于XE7，system.zlib顶部的注释表示使用了zlib 1.2.8。

在zlib代码内部花费时间的明显假设下，对这种行为最合理的解释是64位编译对象导致了性能差。要么是使用的编译器发出了弱代码，要么是使用了不恰当的编译器选项。

于是，我采取了以下步骤：

null

在用于生成问题中数据的同一台机器上运行的时间为6912毫秒。

然后，我重新编译并省略了/O2选项，并再次循环。这一次的运行时间是20,077毫秒。所以我假设Embarcadero只是忘记了用优化来编译这些对象。

我已经向Enbarcadero的质量门户报告了这个问题：https://Quality.embarcadero.com/browse/rsp-9891

null

更新

质量门户问题报告此问题在XE8中已修复。