Changes between Initial Version and Version 1 of FixingPIRVtableOverrides

Show
Ignore:
Timestamp:
03/30/10 05:44:51 (10 years ago)
Author:
chromatic
Comment:

initial creation

Legend:

Unmodified
Added
Removed
Modified
  • FixingPIRVtableOverrides

    v1 v1  
     1Look in the Object PMC's generated C code.  See all of the calls to Parrot_oo_find_vtable_override()?  Isn't that ridiculous? 
     2 
     3Some ~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 
     5We 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 
     12We 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 
     14This is a fairly simple task which will have positive performance implications for not too much work.  Takers welcome.