This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients nanjekyejoannah, nascheme, pablogsal, tim.peters
Date 2019-12-29.03:42:28
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1577590949.24.0.735693967024.issue39143@roundup.psfhosted.org>
In-reply-to
Content
All right!  So, at a first look, "buffering" isn't an obvious disaster ;-)

I'm afraid nailing anything here is hard.  For example, I don't know what you did to "measure memory", but if you're using stats reported by the OS, that's fraught with dangers too.  Python's small-object allocator makes only weak attempts to return memory "to C", which in turn may or may not return memory to "the system".

One way to do better is to call `sys._debugmallocstats()` and stare at the output.  The "# bytes in allocated blocks" output line is an exact count of the number of bytes pymalloc is currently hanging on to for objects that have been allocated but not yet freed.  The point is that C - and the OS - have nothing to do with this value.  The downside:  objects > 512 bytes aren't included at all in this (pymalloc passes on requests for > 512 bytes to the system malloc(), and doesn't keep track of them).

Anyway, so far, so good!  Looks worth pursuing :-)
History
Date User Action Args
2019-12-29 03:42:29tim.peterssetrecipients: + tim.peters, nascheme, pablogsal, nanjekyejoannah
2019-12-29 03:42:29tim.peterssetmessageid: <1577590949.24.0.735693967024.issue39143@roundup.psfhosted.org>
2019-12-29 03:42:29tim.peterslinkissue39143 messages
2019-12-29 03:42:28tim.peterscreate