A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-January/050589.html below:

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

[Python-Dev] Darwin's realloc(...) implementation never shrinks allocations [Python-Dev] Darwin's realloc(...) implementation never shrinks allocationsBob Ippolito bob at redivi.com
Mon Jan 3 17:30:14 CET 2005
On Jan 3, 2005, at 11:15 AM, Guido van Rossum wrote:

> Coming late to this thread.
>
> I don't see the point of lying awake at night worrying about potential
> memory losses unless you've heard someone complain about it. As Tim
> has been trying to explain, here are plenty of other things in Python
> that we *could* speed up if there was a need; since every speedup
> uglifies the code somewhat, we'd end up with very ugly code if we did
> them all. Remember, don't optimize prematurely.

We *have* had someone complain about it: http://python.org/sf/1092502

> Here's one theoretical reason why even with socket.recv() it probably
> doesn't matter in practice: the overallocated string will usually be
> freed as soon as the data has been parsed from it, and this will free
> the overallocation as well!

That depends on how socket.recv is used.  Sometimes, a list of strings 
is used rather than a cStringIO (or equivalent), which can cause 
problems (see above referenced bug).

-bob

More information about the Python-Dev mailing list

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