[fpc-devel] Optimization for TObject.InheritsFrom (and the 'is' operator)

[Bram Kuijvenhoven]

Marco van de Voort wrote:
>> Peter Vreman wrote:
>>> There is no garauntee either within a single unit. With forward defined classes you can make any
>>> order you want.
>>>
>>> And relying on order in memory has also problems with shared libraries. afaik there is no rule
>>> that new libaries are always loaded at larger adresses
>> Thank you for this information, Peter. I hadn't thought of shared
>> libraries yet.
>>
>> Anyway, as far as I understood shared libraries each have their own VMTs,
>> so you can't compare classes that come from different dll's or the main
>> executable. Is that correct?
> 
> For pure shared libraries yes, for packages no.  For packages, Peter is
> right.
>  
>> [...]
> 
> Assume everything on the 1st and 2nd level above is in a package A.
> 
> Progam B and C both use package A. What do we do about lastinsubtree?

Before I could answer that question, I needed to know a little bit more about packages and of how VMTs are handled in packages. ... Found http://wiki.freepascal.org/packages. So I assume we are talking about 'library packages' here.

If a package is loaded dynamically, the preorder indices in the VMTs would need to be recalculated. If it is loaded statically, the compiler can do the calculation on beforehand. Of course the loading of packages must be done synchronized (in a critical section), but that might already have been the case. Also, it should be made possible to enumerate the VMTs that do reside in a package.

I think this outweighs the performance gain for InheritsFrom (and 'is' and 'as'), and it is most beneficial for applications that do not use packages.


BTW does the compiler optimize

  if (obj is TMyObject) then
    SomeCodeWith(obj as TMyObject)

to

  if (obj is TMyObject)
    SomeCodeWith(TMyObject(obj))

(under the condition that SomeCodeWith does not change obj.)


Regards,

Bram