This is definately wierd! As you only mentioned Win9x, I thought I would
give it a go on Win2k.
This is from a CVS update of only a few days ago, but it is a non-debug
build. PII266 with 196MB ram:
1 push 0.001
2 push 0.000
4 push 0.000
8 push 0.000
16 push 0.000
32 push 0.000
64 push 0.000
128 push 0.001
256 push 0.001
512 push 0.003
1024 push 0.006
2048 push 0.011
4096 push 0.040
8192 push 0.043
16384 push 0.103
32768 push 0.203
65536 push 0.583
Things are looking OK to here - the behaviour Tim expected. But then
things seem to start going a little wrong:
131072 push 1.456
262144 push 4.763
524288 push 16.119
1048576 push 60.765
All of a sudden we seem to hit N*N behaviour?
I gave up waiting for the next one. Performance monitor was showing CPU at
100%, but the Python process was only sitting on around 15MB of RAM (and
growing _very_ slowly - at the rate you would expect). Machine had tons of
ram showing as available, and the disk was not thrashing - ie, Windows
definately had lots of mem available, and I have no reason to believe that
a malloc() would fail here - but certainly no one would ever want to wait
and see :-)
This was all definately built with MSVC6, SP3.
no-room-should-ever-have-more-than-one-windows-ly y'rs
Mark.
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