On 30.01.2011 12:06, Jonas Maebe wrote:
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.
Yes and that's why I'm thankful for every suggestion I can get (like
your one).
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 need to scan all pushed symtables can be reduced by keeping the flag
I introduced and using it for this purpose.
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.
Thank you for your suggestion. I'll try to implement this to see whether
it helps.
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.
While I understand the difference between namespaces in case of
Objective-C and Object Pascal, I don't understand why I should pay
attention to the mangling of class helpers. I might be missing a small
puzzle piece here, so would you please explain this?
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
