Message163335
_thread.LockType contains code for sanity checking when the lock is released, and for unlocking it when it is deleted. Both operations involve actually try-lock operations that are costly. Use a flag on the log to keep track of its locking state instead.
Also, acquiring a lock now first tries a try-aqcuire without releasing the GIL, same as _thread.RLock(). This is done by moving logic from RLock.acquire to acquire_timed() so that both locks benefit.
Improvement, on a 64 bit windows machine:
Before:
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock" "allocate_lock()"
1000000 loops, best of 3: 0.725 usec per loop
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
1000000 loops, best of 3: 0.315 usec per loop
After:
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock" "allocate_lock()"
1000000 loops, best of 3: 0.691 usec per loop
D:\pydev\hg\cpython3\PCbuild\amd64>.\python.exe -m timeit -s "from _thread import allocate_lock; l=allocate_lock()" "l.acquire();l.release()"
1000000 loops, best of 3: 0.294 usec per loop
This amounts to 5% and 7% improvement, respectively. |
|
Date |
User |
Action |
Args |
2012-06-21 14:11:40 | kristjan.jonsson | set | recipients:
+ kristjan.jonsson |
2012-06-21 14:11:40 | kristjan.jonsson | set | messageid: <1340287900.16.0.429917171262.issue15124@psf.upfronthosting.co.za> |
2012-06-21 14:11:39 | kristjan.jonsson | link | issue15124 messages |
2012-06-21 14:11:38 | kristjan.jonsson | create | |
|