Kristján Valur Jónsson <krist...@ccpgames.com> added the comment: Two runs with standard locks:
D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.746 usec per loop D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.749 usec per loop Two runs with CV locks (emulated) D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.278 usec per loop D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.279 usec per loop Two runs with CV locks targeted for Vista: D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.272 usec per loop D:\pydev\hg\cpython2>pcbuild\amd64\python.exe -m timeit -s "import _thread; l = _thread.allocate_lock()" l.acquire();l.release() 1000000 loops, best of 3: 0.272 usec per loop You can see the big win from not doing kernel switches all the time. shedding 60% of the time. Once in user space, moving from CriticalSection objects to SRWLock objects is less beneficial, being overshadowed by Python overhead. Still, 2% overall is not to be frowned upon. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11618> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
