[Python-Dev] Memory woes under Windows

[Tim Peters]

Just a brief note on the little list-grower I posted.  Upon more digging
this doesn't appear to have any relation to Dragon's Win98 headaches, so I
haven't looked at it much more.  Two data points:

1. Gordon McM and I both tried it under NT 4 systems (thanks, G!), and
   those are the only Windows platforms under which no MemoryError is
   raised.  But the runtime behavior is very clearly quadratic-time (in
   the ultimate length of the list) under NT.

2. Win98 comes with very few diagnostic tools useful at this level.  The
   Python process does *not* grow to an unreasonable size.  However, using
   a freeware heap walker I quickly determined that Python quickly sprays
   data *all over* its entire 2Gb virtual heap space while running this
   thing, and then the memory error occurs.  The dump file for the system
   heap memory blocks (just listing the start address, length, & status of
   each block) is about 128Kb and I haven't had time to analyze it.  It's
   clearly terribly fragmented, though.  The mystery here is why Win98
   isn't coalescing all the gazillions of free areas to come with a big-
   enough contiguous chunk to satisfy the request (according to me <wink>,
   the program doesn't create any long-lived data other than the list --
   it appends "1" each time, and uses xrange).

Dragon's Win98 woes appear due to something else:  right after a Win98
system w/ 64Mb RAM is booted, about half the memory is already locked (not
just committed)!  Dragon's product needs more than the remaining 32Mb to
avoid thrashing.  Even stranger, killing every process after booting
releases an insignificant amount of that locked memory.  Strange too, on my
Win98 w/ 160Mb of RAM, upon booting Win98 a massive 50Mb is locked.  This is
insane, and we haven't been able to figure out on whose behalf all this
memory is being allocated.

personally-like-win98-a-lot-but-then-i-bought-a-lot-of-ram-ly y'rs
    - tim