-----Original Message----- From: Michael Van Canneyt To: FPC developers' list 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?

At 00:15 7-10-2006, you wrote: >-----Original Message----- >From: Michael Van Canneyt >To: FPC developers' list >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? If you relying on internal typeinfo your program already has a cross-platform issue. So this is not an issue that we change the internal structure. Adding the boolean is possible. But for the array finalize we also need an extra function that will check if the array needs finalization before entering the loop that calls Finalize().