> Someone <wink> may wish to question the historical 10 too. A few weeks ago > on c.l.py, a number of programs were posted showing that, on Linux, the > thread scheduling is such the the *offer* to switch threads every 10 > bytecodes was usually declined: the thread that got the GIL was > overwhelmingly most often the thread that released it, so that the whole > dance was overwhelmingly most often pure overhead. This may be different > under 2.3, where the pthreads GIL is implemented via a semaphore rather than > a condvar. But in that case, actually switching threads every 10 bytecodes > is an awful lot of thread switching (10 bytecodes don't take as long as they > used to <wink>). > > I don't know how to pick a good "one size fits all" value, but suspect 10 is > "clearly too small". In app after app, people who discover > sys.setcheckinterval() discover soon after that performance improves if they > increase it. Let's try 100 and see how that works. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4