We looked at the SecondImport test case today. It's a good test case for programs that execute "import os" in a time-critical inner loop :-). The primary reason it is slower is the import lock that was added after 1.5.2. The benchmark, run in isolation, spends about 6 percent of its time in the locking code. Since it only spends about 20 percent of its time actually doing imports, this is a pretty substantial cost. It seems possible to eliminate some of the cost by using a special marker in sys.modules that means: "This is not a module, but it's being loaded by another thread." But Guido doesn't sound interested in optimizing programs with imports in inner loops. Jeremy
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