A Crazy Thought about CallContext Recycling and Caching

[Austin Hastings]

I've wondered about a similar thing, mostly while listening to all the 
pcc noise a while back.
 
The argument info, parameter info, and mro data seem very amenable to 
caching. Why not rewrite the code in-line? (Sure, there are cases where 
you have to re-check because of blah blah blah whatever, but there are 
also cases where there's only *one* sub named "say" and no reason not to 
cache it.)

=Austin


chromatic wrote:
> Most programs spend most of their time in a few function calls, and most of 
> those function calls have static per-call arity and types.
>
> Our CallContext system allows for the few cases where dynamism is necessary 
> and fails to exploit the relative static nature of most calls in most 
> programs.
>
> We know:
>
> 1) the point of a call
> 2) (generally) the arity of the call
>
> Can we create a cache (perhaps a PMC?) that allows us to skip recycling 
> CallContext PMCs and their register storage locations into the PMC and fixed 
> size pools, using the register size (or the pc of the call) as a key into the 
> cache?
>
> We'd have to detect when it's safe to recycle a CallContext, but we *could* 
> hijack its destroy(), let the GC capture a few, and then store them in the 
> cache by size and avoid subsequent GC runs.
>
> (In a program where 70% of the GCables created are for PCC and where half of 
> the program's time goes to GC, a 35% improvement seems likely.)
>
> -- c
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>