> Where are the attempts to speed up function/method calls? That's an
> area where we could *really* use a breakthrough...
At one time you had entertained treating some of the builtin calls as
fixed. Is that something you want to go forward with? It would entail
a "from __future__" and transitio
Michael Hudson <[EMAIL PROTECTED]> writes:
>> Because there are CO_MAXBLOCKS * 12 bytes in there for the block
>> stack. If there was no need for that, frames could perhaps be
>> allocated via pymalloc. They only have around 100 bytes or so in
>> them, apart from the blockstack and locals/value
At 04:32 PM 2/21/05 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
Hm, actually I think I see the answer; in the case of module-level code
there can be no "anonymous local variables" the way there can in functions.
Why not? There's still a frame object associated with the call
of the anonymous fun
Phillip J. Eby wrote:
Hm, actually I think I see the answer; in the case of module-level code
there can be no "anonymous local variables" the way there can in
functions.
Why not? There's still a frame object associated with the call
of the anonymous function holding the module's top-level code.
T
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 07:00 PM 2/20/05 +, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>> >>Where are the attempts to speed up function/method calls? That's an
>> >>area where we coul
At 07:00 PM 2/20/05 +, Michael Hudson wrote:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>>Where are the attempts to speed up function/method calls? That's an
>>area where we could *really* use a breakthrough...
>
> Amen!
>
> So what happene
At 06:38 PM 2/20/05 +, Michael Hudson wrote:
>> It folds the two steps into a new opcode. In the case of
>> store_name/load_name, it saves one three byte instruction, a trip around
>> the eval-loop, two stack mutations, a incref/decref pair, a dictionary
>> lookup, and an error check (for the
Michael Hudson wrote:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
[SNIP]
And whatever happened to CALL_METHOD?
It didn't work as an optimization, as far as I remember. I think the
patch is on SF somewhere. Or is a branch in CVS? Oh, it's patch
#709744.
Do we need a tp_callmethod that takes an
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>>Where are the attempts to speed up function/method calls? That's an
>>area where we could *really* use a breakthrough...
>
> Amen!
>
> So what happened to Armin's pre-allocated frame patch? Did tha
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> Any objections to new peephole transformation that merges a store/load
>> pair into a single step?
>>
>> There is a tested patch at: www.python.org/sf/1144842
>>
>> It folds the two steps into a new opcode. In the case of
>> store_name/load_name,
Guido van Rossum wrote:
I'm concerned that there's too much hacking of the VM going on with
too little benefit.
I completely agree. It would be so much more useful if people tried
to fix the bugs that have been reported.
Regards,
Martin
___
Python-Dev mai
At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
Where are the attempts to speed up function/method calls? That's an
area where we could *really* use a breakthrough...
Amen!
So what happened to Armin's pre-allocated frame patch? Did that get into 2.4?
Also, does anybody know where all the time g
> Any objections to new peephole transformation that merges a store/load
> pair into a single step?
>
> There is a tested patch at: www.python.org/sf/1144842
>
> It folds the two steps into a new opcode. In the case of
> store_name/load_name, it saves one three byte instruction, a trip around
>
Any objections to new peephole transformation that merges a store/load
pair into a single step?
There is a tested patch at: www.python.org/sf/1144842
It folds the two steps into a new opcode. In the case of
store_name/load_name, it saves one three byte instruction, a trip around
the eval-loop,
14 matches
Mail list logo
