[fpc-devel] Status report for "class helpers"

Jonas Maebe jonas.maebe at elis.ugent.be
Sun Jan 30 12:06:33 CET 2011

On 30 Jan 2011, at 09:45, Sven Barth wrote:

> Only one minute slower in the complete run instead of four. I let you guys decide whether this is good enough ^^

It's still a lot of overhead.

An alternative solution could be to add a hashtable (tfphaslist) to tmodule whose entries are hashed on the qualified class names (unit$classname, since different units can contain classes with the same name). The value of such an entry would a tfpobjectlist of class helpers, with the last entry the one that is actually used. This list has to be updated whenever a symtablestack.push/pop is performed (you would probably have to wrap those calls, since the symtablestack itself is a fairly low level thing and I don't think it is supposed to know anything about tobjectdefs).

The reason for having a list of class helpers rather than only the current class helper, is because you would also have to remove class helpers again when its symtable is removed from the symtable stack, and this way you wouldn't have to search all previous symtables on the stack to see whether they also contained a class helper (simply remove all class helpers from the list whose owner=symtablestack.top).

Of course, this won't be free either since you have to scan all pushed symtables for class helpers, and when popping them you have to go through all hashtable items to remove the appropriate ones. I don't know whether overall it will be faster or slower than your current approach.

The reason the hashtable would have to be kept per module rather than simply adding the list of class helpers in scope to the tabstractrecorddef of the relevant record/class, is that in the latter case you would get into trouble whenever you switch from parsing one unit to another (which happens a lot while parsing uses-clauses). The reason is that you would have to save/restore the current class helpers in scope for every abstractrecorddef that has been loaded whenever you switched units.


PS: the fact that you can have classes with the same name in different units is something that requires special handling in any case. In Objective-C, there is a global class name space (so all classes with the same name are the same class according to the run time), but you probably need different class helper name mangling in the case of Object Pascal to prevent false collisions.

More information about the fpc-devel mailing list