What kept you from doing them in the gc functions?
I wonder if one can be a little naughty and allocate the pike_frames on the stack in those functions. One thing I don't understand though is why most functions carefully avoids having the extra ref during most of the frame's lifetime.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-17 20:56: Subject: pike_frames vs. clone_object/destruct. (7.5)
I have added two new tests to pike -x benchmark, added the --tests='Glob here' argument to be above mentioned program to be able to run only the tests I want to, and then optimized cloning the null pike-class about 20%.
Also, cloning a non-null pike class (one with a create method that actually does something and a local variable) is also faster.
Before:
test total user mem (runs)
Clone null-object.......... 0.502s 0.421s 2936kb (10) Clone object............... 0.800s 0.761s 2936kb (7)
After:
test total user mem (runs)
Clone null-object.......... 0.360s 0.326s 2948kb (14) Clone object............... 0.688s 0.651s 2948kb (8)
On a related note, the same optimizations could rather easily be done to gc_check_object, gc_mark_object_as_referenced and real_gc_cycle_check_object.
The key to the whole thing is that there were a lot of struct pike_frame:s created, initialized, linked and deinitialized unessearily, and this took quite a lot of time.
/ Per Hedbor ()