[fpc-devel] Re: Comparison FPC 2.6.2 - Kylix 3
Sven Barth
pascaldragon at googlemail.com
Mon Mar 4 13:44:39 CET 2013
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.
Regards,
Sven
More information about the fpc-devel
mailing list