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@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

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to