Look in the Object PMC's generated C code. See all of the calls to Parrot_oo_find_vtable_override()? Isn't that ridiculous?
Some ~6% of all of the time spent running Rakudo, if not more, goes to checking if an object's class has a VTABLE override written in PIR. Most don't. Very few do. Yet these get checked on *every* invocation of each of those VTABLE entries.
We can fix this:
- create a dummy VTABLE, where each entry automatically, irrevocably delegates to an overridden PIR VTABLE
- add code to the NameSpace PMC (or wherever's most appropriate) to duplicate the current class VTABLE and swap in the appropriate override pointer when something adds a VTABLE override
- only duplicate that VTABLE once
- make sure to free that duplicate VTABLE when appropriate, lest we leak memory at the end of the program
We may run a small risk of not being able to add overrides when we've already instantiated objects of the given class, but I think that's a low risk (and we can test for that anyway). We already forbid modifications to the class if we've instantiated objects.
This is a fairly simple task which will have positive performance implications for not too much work. Takers welcome.
Tasks:
- Write a small program (Perl 5 is fine, NQP-rx may be better) which parses src/vtable.tbl
- generate a dummy VTABLE
- each VTABLE entry should only fetch a PIR sub override and invoke it with the given arguments
- see lib/Parrot/Pmc2c/PMC/Object.pm around line 68
- store this dummy VTABLE somewhere where the interpreter can get to it
- Add code to the NameSpace PMC to detect adding a vtable override
- when this happens, clone the current VTABLE (unless it's already been cloned once)
- swap in the appropriate pointer from the dummy VTABLE
- store the new VTABLE where instances of the class can use it
- (hands wave here; probably Class needs to install it for Object)
- add code to Class (or whatever stores the cloned version) to delete the cloned VTABLE
- Remove the special cases from lib/Parrot/Pmc2c/PMC/Object.pm
That's it!
