I have pushed a new version of the faster calls branch. I readded support for profiling. I also fixed one more open bug. Of course there may more more. Performance-wise the situation did not change since the conference, but I have done some experimentation to improve it. One follow-up change will probably be a re-work of the function call API used from within interpreter. I also want to add more tail call optimizations where missing. Current comparison to 8.1 on my intel:

interpreter/automap.pike#efun | 27.8 M 0.4 % | 41.1 M 0.6 % | interpreter/automap.pike#private | 17.3 M 0.7 % | 25.8 M 0.3 % | interpreter/automap.pike#public | 17.6 M 0.2 % | 26.1 M 0.1 % | interpreter/call.pike#efun |173.9 M 0.6 % |171.6 M 0.8 % | interpreter/call.pike#index | 15.7 M 0.4 % | 14.3 M 0.4 % | interpreter/call.pike#private | 20.9 M 0.5 % | 18.7 M 0.2 % | interpreter/call.pike#public | 21.1 M 0.2 % | 18.6 M 0.4 % | interpreter/call_array.pike#efun | 23.7 M 0.1 % | 34.1 M 0.3 % | interpreter/call_array.pike#private | 15.6 M 0.3 % | 14.1 M 0.1 % | interpreter/call_array.pike#public | 15.3 M 0.3 % | 14.0 M 0.1 % | interpreter/map.pike#efun | 41.8 M 0.4 % | 37.0 M 0.5 % | interpreter/map.pike#private | 15.7 M 0.5 % | 22.9 M 0.4 % | interpreter/map.pike#public | 16.0 M 0.1 % | 22.9 M 0.2 % | interpreter/recurse.pike#private | 27.9 M 0.4 % | 38.1 M 0.3 % | interpreter/recurse.pike#public | 27.7 M 0.2 % | 37.2 M 0.7 % | interpreter/tailcall.pike#private | 20.6 M 0.4 % | 31.4 M 0.4 % | interpreter/tailcall.pike#public | 21.0 M 0.2 % | 30.7 M 0.5 % |

As you can see, the only slow-downs currently are in standard lfun calls. I believe this can be fixed using some refactoring of the corresponding opcodes. I believe that we can also come up with a simpler API which can more easily be called directly from machine code.

I think the branch is now in a state in which it could be merged into 8.1. I expect that there are still some issues which will come up when running more complex code bases. I did write a test-suite which tries to cover all different function call types and I will integrate that into the standard testsuite soon.

Unless anyone sees any issue with the code as it stands, I will use the decision reached during the conference and merge this within the next week or so.

Arne