Hello, On Fri, 3 Apr 2020 09:34:44 +1100 Chris Angelico <rosuav@gmail.com> wrote:
On Fri, Apr 3, 2020 at 9:20 AM Paul Sokolovsky <pmiscml@gmail.com> wrote:
But not exactly. Let me humbly explain what's really a cost. It's looking at PyObject_HEAD https://swenson.github.io/python-xr/Include/object.h.html#line-78 (damn, that's Python2 source, stupid google), and seeing that it's at least:
Py_ssize_t ob_refcnt; \ struct _typeobject *ob_type;
That's 2 word-sized fields, 16 bytes on 64-bit machine. You can dig further and further, and understand, how much memory it takes to store so-and-so kind of structure (and how it could be done differently).
That's fair, but the PyObject* header isn't the only cost. The actual data for a Python string isn't stored in the structure. How do you know how much memory is being consumed by that? Are you 100% certain that sys.getsizeof() is measuring that?
As I mentioned in another reply, I would look into (temporarily) patching sys.getsizeof() to return true allocation size. As we speak of it, there's another issue. Consider an object consisting of two allocations, say 16-byte header, containing a pointer to another allocation, mere 4 bytes. It would seem that the object takes 20 bytes, but the matter that there's "allocation granularity". If it's 16 bytes, then the true memory cost is 32 bytes. In in blissful distant future I would add a flag to sys.getsizeof() requesting either "internal" object size (as (apparently) returned now) or "external" as described. Anyway, this gets offtopic (or premature discussion). ;-) [] -- Best regards, Paul mailto:pmiscml@gmail.com