Delphi XE2 64-bit extremely slow runtime performance on string routines

Question

I'm porting some applications from 32 to 64 bits delphi, which do a lot of text processing, and noticed an extreme change in processing speed. Did some tests with a few procedures, for example, this takes already more than 200% the time in 64bits than compiling to 32 (2000+ ms compared to ~900)

Is this normal?

function IsStrANumber(const S: AnsiString): Boolean; var P: PAnsiChar; begin   Result := False;   P := PAnsiChar(S);   while P^ <> #0 do begin     if not (P^ in ['0'..'9']) then Exit;     Inc(P);   end;   Result := True; end;  procedure TForm11.Button1Click(Sender: TObject); Const x = '1234567890'; Var a,y,z: Integer; begin   z := GetTickCount;   for a := 1 to 99999999 do begin    if IsStrANumber(x) then y := 0;//StrToInt(x);   end;   Caption := IntToStr(GetTickCount-z); end; 

Answer 1

There is no current solution for this, as it is caused by the fact that the code for most of the string routines in 64 bit is compiled with PUREPASCAL defined, IOW, it is plain Delphi, no assembler, while the code for many of the important string routines in 32 bit was done by the FastCode project, and in assembler.

Currently, there are no FastCode equivalents in 64 bit, and I assume that the developer team will try to eliminate assembler anyway, especially since they are moving to more platforms.

This means that optimization of the generated code becomes more and more important. I hope that the announced move to an LLVM backend will speed up much of the code considerably, so pure Delphi code is not such a problem anymore.

So sorry, no solution, but perhaps an explanation.

Update

As of XE4, quite a few FastCode routines have replaced the unoptimized routines I talk about in the above paragraphs. They are usually still PUREPASCAL, but yet they represent a good optimization. So the situation is not as bad as it used to be. The TStringHelper and plain string routines still display some bugs and some extremely slow code in OS X (especially where conversion from Unicode to Ansi or vice versa is concerned), but the Win64 part of the RTL seems to be a lot better.