While sitting on IRC with Dan and Jonathan discussing how to optimizer a certain construct with how we handle globals/package variables, etc. I came to the conclusion that it would be valuable to not have to fetch each and every global, lexical or package variable by name, individually, but instead fetch them in clusters (4-16 at a time).
We already have register frames which are saved and restored very efficiently.
For instances where a module has package variables and globals, there exists an overhead upon repeatedly invoking a sub in one of those modules.
I believe it would be quite handy to store register frames off for random access (not on the pad stack). The access could either be by name, or stashed in a PMC and held on the stack itself.
IMCC could analyze a module, decide if the optimization makes sense, and place commonly used values (constants or variables) in a pre-packaged register frame. (or more than 1) This is done at compile / load time of course. If it were all constants, compile time works, but for PMCs and Strings it would have to be built at loadtime.
Upon invoking a busy routine, it _might_ be more efficient (since we already save register frames anyway) to initialize the upper frame (top 16 registers) with a pre-built register set.
It might also be more useful to have it more granular than 16, maybe in 4s or 8s. By doing life analysis and some weighting, IMCC might be able to turn multiple symbol lookups into 1.
Comments & questions welcome.
-Melvin
