[Python-Dev] Darwin's realloc(...) implementation never shrinks allocations

[Andrew P. Lentvorski, Jr.]

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