[Python-Dev] Darwin's realloc(...) implementation never shrinks allocations (original) (raw)
Bob Ippolito bob at redivi.com
Mon Jan 3 17:30:14 CET 2005
- Previous message: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
- Next message: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
- Next message: [Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]