[issue2179] with should be as fast as try/finally

2008-03-09 Thread Jeffrey Yasskin
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

[issue2179] with should be as fast as try/finally

2008-03-07 Thread Nick Coghlan
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 __

[issue2179] with should be as fast as try/finally

2008-03-07 Thread Nick Coghlan
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

[issue2179] with should be as fast as try/finally

2008-03-07 Thread Amaury Forgeot d'Arc
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

[issue2179] with should be as fast as try/finally

2008-03-07 Thread Jesús Cea Avión
Changes by Jesús Cea Avión: -- nosy: +jcea __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2179 __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2179] with should be as fast as try/finally

2008-03-06 Thread Amaury Forgeot d'Arc
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

[issue2179] with should be as fast as try/finally

2008-03-02 Thread Jeffrey Yasskin
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

[issue2179] with should be as fast as try/finally

2008-03-01 Thread Nick Coghlan
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

[issue2179] with should be as fast as try/finally

2008-03-01 Thread Nick Coghlan
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 __

[issue2179] with should be as fast as try/finally

2008-02-24 Thread Jeffrey Yasskin
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

[issue2179] with should be as fast as try/finally

2008-02-24 Thread Collin Winter
Changes by Collin Winter: -- nosy: +collinwinter __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2179 __ ___ Python-bugs-list mailing list Unsubscribe: