[fpc-devel] TList slowness in classes

[Michalis Kamburelis]

Michael Van Canneyt wrote:
> 
> On Fri, 24 Dec 2004, 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.
> 
> 
> This is because there is an extra (implicit) Try/Finally block.
> 
> Michael.
> 

Thank you and Peter for answers. This way I was able to see how 
try...finally section looks in assembler :) Anyway, I understand that 
the answer is "can't be speed up". OK, I can live with that.

-- 
Michalis