IntToStr / StrToInt Perf issues VS Delphi?

[derek.john.evans]

I could be wrong, but on Win32 InToStr() maps to System.Str().

Code: [Select]

function IntToStr(Value: integer): string;
begin
 System.Str(Value, result);
end ;

StrToInt maps to Val().

Code: [Select]

function StrToInt(const S: string): integer;
var Error: word;
begin
  Val(S, result, Error);
  if Error <> 0 then raise EConvertError.createfmt(SInvalidInteger,[S]);
end ; 

Thus, a speed up can be achieved just by bypassing StrToInt/IntToStr.

[rvk]

I could be wrong, but on Win32 InToStr() maps to System.Str().

Code: [Select]

function IntToStr(Value: integer): string;
begin
 System.Str(Value, result);
end ;


And System.Str() is dependent on either the int_str() in generic.inc in pure pascal (for cross-platform) or the int_str() in i386.inc which is pure assembler. So my guess would be that the pure assembler would be much better. But FPC also does A LOT (and I mean A LOT) of ShortToAnsiString and other stuff with a simple IntToStr() while Delphi just has one pure assembler function.

So you're correct... if speed is of importance the best thing is to create a new IntToStr() in pure pascal and use that.

[Handoko]

I could be wrong, but on Win32 InToStr() maps to System.Str().

Code: [Select]

function IntToStr(Value: integer): string;
begin
 System.Str(Value, result);
end ;


That's right. On my Lazarus 64-bit Linux, it also maps to System.Str().

Tested the perfomance gain by bypassing StrToInt/IntToStr, unfortunately the gain is very small.

Original:
10000000, It took 2.956 secs

Using System.Str() directly:
10000000, It took 2.919 secs

Performance gain:
= (2.956 - 2.919) / 2.956 * 100%
= 1.25%

I have to admit, FPC/Lazarus is not well optimized compare to Delphi. That's understandable, Delphi is commercially/financially supported, it's expensive (for me). FPC/Lazarus is cross-platform supported by volunteers, the developers spend more time to make it cross-platform rather than optimizing it.

[rvk]

That's right. On my Lazarus 64-bit Linux, it also maps to System.Str().

On all systems and platforms it maps to System.Str(). It's what that function looks like that's important. You'll notice you can't trace through it on Laz1.4 (production version) but if you have trunk you can trace through all the code (F7) and you'll see it ending up in a int_str() function which is platform dependent (or in generics.inc if there is no platform dependent int_str()). (There are only 2 implementations. The pure pascal in generics.inc and the assembler one in i386.inc)

So the speed difference you mention with System.Str() doesn't say a lot (it's just one extra less call per iteration). You should replace System.Str() with a real assembler function (like in Delphi). Then you'll see a real difference. The IntToStr() in Delphi is in SysUtils.pas (at least it was in XE) and is pure assembler.

I was hopeful when forcing FPC to use the int_str() assembler version in i386.inc but because there is a lot of extra overhead with string-conversion and some other extra functions there was no real speed improvement. Just like you said... FPC is more optimized for cross-platform than for speed.