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

[bacchusrx]

On Thu, Jan 01, 1970 at 12:00:00AM +0000, Tim Peters wrote:
> 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?
> 
> [...]
> 
> I agree the socket-abuse case should be fiddled, and for more reasons
> than just Darwin's realloc() quirks. [...] Yes, in the socket-abuse
> case, where the program routinely malloc()s strings millions of bytes
> larger than the socket can deliver, it would obviously help.  That's
> not typically program behavior (however typical it may be of that
> specific app).

Note that, with respect to http://python.org/sf/1092502, the author of
the (original) program was using the documented interface to a file
object.  It's _fileobject.read() that decides to ask for huge numbers of
bytes from recv() (specifically, in the max(self._rbufsize, left)
condition). Patched to use a fixed recv_size, you of course sidestep the
realloc() nastiness in this particular case.

bacchusrx.