[fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3

Mattias Gaertner nc-gaertnma at netcologne.de
Mon Mar 4 14:43:24 CET 2013


On Mon, 4 Mar 2013 14:18:09 +0100 (CET)
marcov at stack.nl (Marco van de Voort) wrote:

> In our previous episode, Mattias Gaertner said:
> > > are 50 units loaded, this means 50 symtable lookups, simply because the 
> > > operator might be overloaded.
> > 
> > Is there no cache?
> > Something like: Give me all '+' operator overloads in all used units
> > of interface, implementation.
> 
> >From what I understand of pascal parsing:
> 
> You need the implementation highest in the scope stack. "all" doesn't help,
> and they can also be implemented in the unit (or even local?) scope.

Yes, the compiler has to search first local and inherited scopes, which
need all kind of special rules, so caching might not help here. 
But after searching the special scopes the compiler has to search the
interface sections of all used units. And these results should be the
same for the whole implementation section. So it sounds like a good
candidate for caching.

 
> One would need to build the cache lazily (on first access in a scope), and
> somehow avoid rebuilding too often if the scope changes.

Yes. Or make the cache not too specific. For example just cache the
list of all operator overloads. The compiler still has to check each
operator, but it does not have to search all symtables to gather all
operators.
Or it can cache what operator does not have any overloads at all and
can simply use the default.

 
> > > The situation with Pascal type conversion has grown increasingly complex 
> > > over the years. For example almost any type can be converted into a 
> > > variant, and a variant can be converted into almost any type. This 
> > > requires all kinds of special handling, not only to do the right thing, 
> > > but also not to do ineffcient type conversions.
> > 
> > Can this be cached?
> > Maybe the compiler can reuse some results?
> 
> No I think not. The context to be checked is probably too large/complex.


Mattias



More information about the fpc-devel mailing list