[fpc-devel] TList slowness in classes

[Ales Katona]

Michalis Kamburelis wrote:

> Hi,
>
> I tested your code and found that indeed version in ucopylist is 
> slightly faster (by about 9.5 / 7 =~ 1.357). Two things:
>
> 1. Speedup is only 1.357x, not 3x, like you said. Are you sure that 
> you're getting 3x speedup ? On what OS and with what FPC version are 
> you testing this ? I was doing tests with Linux/i386 with FPC 1.9.4 
> and 1.9.5 (from CVS 2004-12-20).
>
> 2. Still, speedup 1.357x may be significant in some cases so I 
> investigated what's the cause:
>
> After many tests I found that this slight speedup is caused by the 
> fact that in ucopylist you declared string constants SListIndexError, 
> SListCapacityError and SListCountError as normal constants while with 
> original Classes unit these constants are taken from RTLConst unit 
> that defines them as resourcestrings.
>
> Using resourcestrings in RTL is a must, since this allows to translate 
> error messages without modifying unit Classes sources.
>
> However in this case exceptions are not raised, so resourcestrings are 
> not actually used. But it looks that any procedure that uses some 
> resourcestring in implementation is doomed to be slower than the 
> similar procedure that instead uses normal string consts, *even if 
> this procedure doesn't actually access the string at runtime*. It 
> seems that if some procedure uses resourcestring then upon entry it 
> does some lengthy initialization of this resourcestring, even if it 
> will not actually make use of that resourcestring.
>
> I'm attaching a simple demo program that shows this. When compiled like
>   fpc -OG -O2 -Op2 demo_resourcestring_slow.pas
> (to get maximum optimizations) sample output of it is
>   Time of Foo_Normal:         16
>   Time of Foo_ResourceString: 106
> So time difference is really noticeable. Question goes to FPC 
> developers, maybe such cases with using resourcestrings can be speed up ?
>
> Regards,
>
>------------------------------------------------------------------------
>
>{$mode objfpc}{$H+}
>
>uses
>  {BaseUnix, Unix needed only to implement Clock} BaseUnix, Unix,
>  SysUtils;
>
>function Clock: Int64;
>var Dummy: tms;
>begin
> Clock := FpTimes(Dummy);
>end;
>
>const
>  SNormal    = 'blah blah blah blah blah blah blah blah blah blah';
>resourcestring
>  SResString = 'blah blah blah blah blah blah blah blah blah blah';
>
>{ Foo_Normal and Foo_ResourceString do the same thing,
>  but Foo_Normal uses normal string constant while
>  Foo_ResourceString uses resourcestring. }
>
>procedure Foo_Normal(i: Integer);
>begin
> if i = -1 then raise Exception.Create(SNormal);
>end;
>
>procedure Foo_ResourceString(i: Integer);
>begin
> if i = -1 then raise Exception.Create(SResString);
>end;
>
>
>{ Note that when I call Foo_Normal and Foo_ResourceString
>  i is always >= 0 so Exception is never actually raised.
>  So string constants SNormal and SResString are not really used. }
>
>const
>  TestCount = 10000000;
>var
>  i: Integer;
>  Start: Int64;
>begin
> Start := Clock;
> for i := 0 to TestCount do Foo_Normal(i);
> Writeln('Time of Foo_Normal:         ', Clock - Start);
>
> Start := Clock;
> for i := 0 to TestCount do Foo_ResourceString(i);
> Writeln('Time of Foo_ResourceString: ', Clock - Start);
>end.
>
>------------------------------------------------------------------------
>
>_______________________________________________
>fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>http://lists.freepascal.org/mailman/listinfo/fpc-devel
>  
>
The slowness 3x I ment was not between atomics like get/put but when I 
tested a bigger(10000x10000) bubblesort with the copy and original. The 
times back then I got were about:
Original: ~28seconds
Copy: ~6seconds

This is even more than 3x.(ups ;-) ) In any case the point is in 
critical operations these things can be real problematic. Another 
interresting fact is that ListArray from java(almost same thing as our 
TList) was about 8 seconds with same test.

Don't get me wrong, I'm not trying to reasure myself here, it's just 
that I think it can be made faster nothing else.

The resourcestrings are interresting. I'd look at the code but I'm 
afraid that's a bit too deep RTL for me...


Ales