> I am not sure how to benchmark such modifications. Is there any
> benchmark that includes threaded use of the same functions in typical
> use cases?
I don't think it's necessary to benchmark that specific case -
*any* kind of micro-benchmark would be better than none.
If you want to introduce fr
On 6/10/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Note that _only_ recursions will have more than 1 frame attached.
>
> That's not true; in the presence of threads, the same method
> may also be invoked more than one time simultaneously.
Yes, I have missed that, and realized that I miss
> Note that _only_ recursions will have more than 1 frame attached.
That's not true; in the presence of threads, the same method
may also be invoked more than one time simultaneously.
> But removing freelist altogether will not work well with any type of
> recursion.
How do you know that? Did yo
The freelist currently serves as a good optimization of a special case
of a recurring recursion. If the same code object (or one of the same
size) is used for recursive calls repeatedly, the freelist will
realloc-to-same-size (which probably has no serious cost) and thus the
cost of allocating/dea
> Should I make a patch?
-1. This could consume quite a lot of memory, and I doubt
that the speed improvement would be significant. Instead,
I would check whether performance could be improved by
just dropping the freelist. Looking at the code, I see
that it performs a realloc (!) of the frame obj
