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
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to