Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Thanks Nick and Amaury!
Amaury, what times are you seeing? It could be a just-gcc speedup, but I
wouldn't have thought so since the patch eliminates 2 times around the
eval loop. It could be that the overhead of WITH_CLEANUP is high enough
to
Nick Coghlan added the comment:
Patch applied cleanly for me and all tests pass.
It also looked good on a visual scan over the diff text.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2179
__
Nick Coghlan added the comment:
I went ahead and committed the change to the bytecode generation as r61290.
The deficiencies in the lock implementation should probably be raised as
a separate issue, so I'm closing this one.
--
resolution: - accepted
status: open - closed
Amaury Forgeot d'Arc added the comment:
Hm, my tests do not see any speedup with this patch.
I used VS2005 on win2K, and VS2008 on winXP.
Timings are very similar before and after this patch.
Maybe the optimization is only useful with gcc?
__
Tracker [EMAIL
Changes by Jesús Cea Avión:
--
nosy: +jcea
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2179
__
___
Python-bugs-list mailing list
Unsubscribe:
Amaury Forgeot d'Arc added the comment:
What's strange is that calling __enter__ and __exit__ in a
try/finally block brings the speed back to the faster 'with' speed,
even though they call the same C functions
Looking carefully at the code, there are two reasons for this:
- LockType has no
Jeffrey Yasskin added the comment:
Here's a proof-of-concept patch that keeps the __exit__ method on the
stack. It uses ROT_TWO to stuff it under the context object instead of
storing it into a temporary. (Thanks Nick for pointing out that problem
before I had to waste time on it.) test_with
Nick Coghlan added the comment:
A closer approximation of what the with statement is doing would be:
exit = lock.release()
lock.acquire()
try:
pass
finally:
exit()
The problem with trying to store the result of the retrieval of __exit__
on the stack is that we need to leave the context
Nick Coghlan added the comment:
Scratch the parentheses on that first line of sample code in my previous
comment (isn't copy and paste wonderful?)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2179
__
New submission from Jeffrey Yasskin:
Currently, 'with' costs about .2us over try/finally:
$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally:
lock.release()'
100 loops, best of 3: 0.617 usec per loop
$ ./python.exe -m timeit -s
Changes by Collin Winter:
--
nosy: +collinwinter
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2179
__
___
Python-bugs-list mailing list
Unsubscribe:
11 matches
Mail list logo