Yes, I see. I will merge the new block alloc and keep the new pike_frame code. I have probably not read it properly, then. I tried to benchmark, but current 7.9 doesnt work for me, right now.
arne
On Wed, 12 Jun 2013, Per Hedbor () @ Pike (-) developers forum wrote:
Using malloc/free as in cc0851de980d46e85e514657d8d9a484fe8be2eb is certainly much faster than the old worst case behavior. I would guess the new block allocator is faster than malloc/free, so I propose to overwrite cc0851de980d46e85e514657d8d9a484fe8be2eb by this. Any objections?
I am not entirely certain it is actually faster than the new pike_frame code.
That one actually never calls free, and only calls malloc every 8Kb of pikeframes. It is almost impossible to write something that is faster, the only way is to remove the accounting (num_*++ in the allocator and the deallocator, which about doubles the speed)
There is of course tradeoffs. It, as mentioned, never returns memory to the system.
A better solution for the future would probably be to keep the frames on the stack, and then duplicate them when needed for the scope code, (and by necessity change the calling convention for pike functions from addr=mega_apply(...);*addr() to mega_apply(), which is already how C functions and efuns work)
-- Per Hedbor