summaryrefslogtreecommitdiffstats
path: root/Objects
diff options
context:
space:
mode:
authorTim Peters <tim.peters@gmail.com>2002-08-01 02:23:06 (GMT)
committerTim Peters <tim.peters@gmail.com>2002-08-01 02:23:06 (GMT)
commit2d8b765cc958f06bc424ea43c6af890f652e1c4c (patch)
tree772c388c41e734ed0cf59150597682956e2ddc64 /Objects
parenta64dc245ac18ad766d256a38efacad8a62671407 (diff)
downloadcpython-2d8b765cc958f06bc424ea43c6af890f652e1c4c.zip
cpython-2d8b765cc958f06bc424ea43c6af890f652e1c4c.tar.gz
cpython-2d8b765cc958f06bc424ea43c6af890f652e1c4c.tar.bz2
New test for sorting sanity. Note that this will fail in earlier Pythons,
in the stability tests. 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).
Diffstat (limited to 'Objects')
0 files changed, 0 insertions, 0 deletions