[Python-checkins] python/dist/src/Lib/test test_sort.py,NONE,1.1

[Andrew MacIntyre]

On Wed, 31 Jul 2002 tim_one@users.sourceforge.net wrote:

> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory usw-pr-cvs1:/tmp/cvs-serv24012
>
> Added Files:
> 	test_sort.py
> Log Message:
> 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).

Hmmm, perhaps this was the sort of dragon you had in mind when you
suggested I persist with PyMalloc'ing the parser on top of your
overallocation strategy?  It'd be worth a test with either my experimental
or "final" patch(es)?

Its mind boggling how many small mallocs in PyNode_AddChild() test_longexp
generates (853016 total PyNode_AddChild() requests according to my logging
harness, all bar 92(!) of which are for the n=1 case).

--
Andrew I MacIntyre                     "These thoughts are mine alone..."
E-mail: andymac@bullseye.apana.org.au  | Snail: PO Box 370
        andymac@pcug.org.au            |        Belconnen  ACT  2616
Web:    http://www.andymac.org/        |        Australia