[Python-Dev] Darwin's realloc(...) implementation never shrinks allocations
Bob Ippolito
bob at redivi.com
Mon Jan 3 17:30:14 CET 2005
More information about the Python-Dev mailing list
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 ]
More information about the Python-Dev mailing list