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