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

[Michael Van Canneyt]

On Mon, 4 Mar 2013, Sven Barth wrote:

> Am 04.03.2013 13:38, schrieb Daniël Mantione:
>> 1. Operator overloading
>> 
>> Operators are some of the most common tokens in source code. Without 
>> operator overloading, if you parse an operator, you simply generate a tree 
>> node.
>> 
>> With operator overloading, for each operator that you parse, you have to 
>> traverse all loaded units to check if the operator is overloaded. If there 
>> are 50 units loaded, this means 50 symtable lookups, simply because the 
>> operator might be overloaded.
>> 
>> For each operator overload candidate that is found, the compiler has
>> need to check for many possible type conversions to see if the candidate 
>> can actually be used.
>> 
>> 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.
>> 
>> So even if you don't use operator overloading or variants at all, they do 
>> affect the compiler speed.
>> 
> Maybe we can improve this situation. For class helpers I added the 
> possibility to add flags to symtables (so that only units are checked that 
> really contain class helpers). Maybe we can add an additional "has_operators" 
> flag and ignore all units when searching for overloads that don't have this 
> flag set (the flag would propagate from the symtable of e.g. advanced records 
> up to the unit symtable when parsing the record's declaration). As most units 
> don't declare operators this could result in a little speedup especially 
> considering that the lookup is done on each operator... and then we might add 
> some caching structures to improve this further.

That seems simple enough to implement and test ?

Michael.