More inlining

Speaking of inlining (and here), why not an ability to inline virtually any function? Performance benefits from inlining simple functions might be significant, since function call in PHP is not cheap. We’d have some potential problems there:

  1. Variable scoping – we don’t want function variables to mess with our scope, so we’d probably rename them or something.
  2. Renaming variables of course is dangerous with functions that mess with current scope like extract() – so maybe such code can’t be inlined.
  3. Then we might get a problem if function messing with current scope is called indirectly so we can’t really know. Banning indirect function calls for inlining isn’t much of a problem too – I don’t think it’s used that much.
  4. Also, there might be functions that care about their own scope and having variables from external scope would drive them crazy even if their own variables are OK. I don’t know any such code but maybe it exists. So then we probably would have to give developer means to ensure some functions are never inlined.
  5. And then some may use end-of-scope for destruction of variables that have dtors, so when we’d clean up these variables? We can of course generate “free” opcodes at the end of the inlined call, but it’s be probably slowing the things down…

So, it’s not as easy as one might like it to be. But interesting, in my opinion.


One thought on “More inlining

  1. Pingback:

Comments are closed.