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

[Sven Barth]

Am 04.03.2013 16:16, schrieb Sven Barth:
> Am 04.03.2013 14:31, schrieb Sven Barth:
>> Am 04.03.2013 13:46, schrieb 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 ?
>>>
>> Yes, maybe I'll give it a try in the next couple days (if no one 
>> beats me :) ).
> It seems that I only achived around 0.1 to 0.2 seconds when compiling 
> the compiler (manually, with -B). But it's now checking only unit 
> System and unit constexp (part of the compiler) for operator overloads.
>
> It's also interesting to see that not every unit triggers a search for 
> operators...
And compiling with 2.6.0 is around 0.1 to 0.3 seconds faster.

And before I forget it: Platform is i386-win32.

Regards,
Sven