On Jan 2, 2005, at 11:16 PM, Tim Peters wrote: > [Bob Ippolito] >> However, it is our (in the "I know you use Windows but I am not the >> only >> one that uses Mac OS X sense) problem so long as Darwin is a supported >> platform, because it is highly unlikely that Apple will backport any >> "fix" to >> the allocator unless we can prove it has some security implications in >> software shipped with their OS. ... > > Is there any known case where Python performs poorly on this OS, for > this reason, other than the "pass giant numbers to recv() and then > shrink the string because we didn't get anywhere near that many bytes" > case? Claiming rampant performance problems should require evidence > too <wink>. Possibly. When using the stock btdownloadcurses.py from bitconjurer.org, I occasionally see a memory thrash on OS X. Normally I have to be in a mode where I am aggregating lots of small connections (10Kbps or less uploads) into a large download (10Mbps transfer rate on a >500MB file). When the file completes, Python sends OS X into a long-lasting spinning ball of death. It will emerge after about 10 minutes or so. I do not see this same behavior on Linux or FreeBSD. I never filed a bug because I can't reliably reproduce it (it is dependent upon the upload characteristics of the torrent swarm). However, it seems to fit the bug and diagnosis. -a
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