| | 1 | Look in the Object PMC's generated C code. See all of the calls to Parrot_oo_find_vtable_override()? Isn't that ridiculous? |
| | 2 | |
| | 3 | 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. |
| | 4 | |
| | 5 | We can fix this: |
| | 6 | |
| | 7 | * create a dummy VTABLE, where each entry automatically, irrevocably delegates to an overridden PIR VTABLE |
| | 8 | * 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 |
| | 9 | * only duplicate that VTABLE once |
| | 10 | * make sure to free that duplicate VTABLE when appropriate, lest we leak memory at the end of the program |
| | 11 | |
| | 12 | 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. |
| | 13 | |
| | 14 | This is a fairly simple task which will have positive performance implications for not too much work. Takers welcome. |
