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

[Sven Barth]

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