Re[2]: [fpc-devel] rtti, arrays and performance

[vlad vladovich]

-----Original Message-----
From: Michael Van Canneyt <michael at freepascal.org>
To: FPC developers' list <fpc-devel at lists.freepascal.org>
Date: Fri, 6 Oct 2006 22:01:55 +0200 (CEST)
Subject: Re: [fpc-devel] rtti, arrays and performance


> Did you see a change in performance ? Can you give an order of magnitude ?
>

For me Shark profiler shows that 60%-70% of time spent in fpc_finalize (this is on intel core duo, havn't measured on powerpc). After change it shown just a few percents (I do not remember exactly, and it's a little bit hard to measure exactly because this block is performd in a few seconds now). But it's just a mine specific case. I use dynamic arrays heavily there, too much, it would be better to use getmem there and then type cast it as pointer to array. Generally speaking I think that it's not a significant optimization for most of applications. Just it was easer for me to tweak rtl than to change my code :). But anyway - if I have array of integer with a hundreds thousand items call to finalize each item is not really good I think. What if user has record with array inside, and that record has some dynamic variable? as I understand fpc_finalize will try to finalize array too... And as I understand dynamic arrays always finalizing their items.
 
> 
> I think it may be indeed a better idea to see whether the compiler can set a flag in the type info:
> 
> If we change TTypeInfo to
> 
>    TTypeInfo = record
>      Kind : TTypeKind;
>      Finalize : Boolean;
>      Name : ShortString;
>      // here the type data follows as TTypeData record
>    end;
> 
> Then there is no need for a recursive loop (the compiler has already done that...); 
> Only the Finalize field needs to be retrieved. Putting this field in the middle will
> make sure 99,9% of all existing code will still work.
> 

I don't know is this good - perhaps to not break other's code such attribute can be placed before type info record (at offset -1 or -4 from typeinfo pointer:)),so, if somebody relies on current typeinfo format his code will be not broken?