[Tim, in python-checkins] > Bizarre: this takes 11x longer to run if and only if test_longexp is > run before it, on my box. The bigger REPS is in test_longexp, the > slower this gets. What happens on your box? It's not gc on my box > (which is good, because gc isn't a plausible candidate here). > > The slowdown is massive in the parts of test_sort that implicitly > invoke a new-style class's __lt__ or __cmp__ methods. If I boost > REPS large enough in test_longexp, even the test_sort tests on an array > of size 64 visibly c-r-a-w-l. The relative slowdown is even worse in > a debug build. And if I reduce REPS in test_longexp, the slowdown in > test_sort goes away. > > test_longexp does do horrid things to Win98's management of user > address space, but I thought I had made that a whole lot better a month > or so ago (by overallocating aggressively in the parser). It's about the same on my Linux box (system time is CPU time spent in the kernel): test_longexp alone takes 1.92 user + 0.22 system seconds. test_sort alone takes 1.71 user + 0.01 system seconds. test_sort + test_longexp takes 3.62 user + 0.18 system seconds. test_longexp + test_sort takes 38.05 user and 0.34 system seconds!!! I'll see if I can get this to run under a profiler. --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