-----Original Message-----
From: Michael Van Canneyt <[EMAIL PROTECTED]>
To: FPC developers' list <fpc-devel@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?
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to