> The problem with inlining methods from PMC vtables is it assumes those > vtable methods are constant. They're not.
They're not constant universally, but the are constant locally. In those locales that inlining is worth the cost we can do it. And as long as we are willing to take the hit in overhead to track when our assumptions are wrong, and re-assemble on the fly when we botched, we might win. I'm not saying that we are going to win all the time, or that this isn't tricky, or even that we SHOULD do it. What I'm saying is I think the potential payout (especially if one ever starts compiling direct to bare hardware) may be worth the cost of a rethink. > The only time we can safely bypass the vtable indirection is when all of > the following are true: > > *) The program is fully parsed If the program isn't parsed fully enough that we don't know what something is that means that we may not be able to reasonably inline it. It means inlining is a high risk activity, if we do it, we'll have to undo it when we parse the bit that tells us that we shouldn't have done it orignally. > *) There are no string eval, do, or requires As soon as you generate code on the fly, or have code which modifies other code, you're already whipping out the assembler again. The trick would be figuring out what nastiness the new compilation brings with it. When the eval'd string is compiled is may not do anything that would kill existing vtables. Basically this is the same argument as your first point... > *) There are no symbolic references on the LHS of any assignment I would appreciate it if you explain this further, the rationale. Some times we want to use vtablesness, but I can't see how this negates all applications of inlining. > *) There is no use of MY within the block or in any subs called by the block I don't see what you are implying here. Could you explain this a bit more?
