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 methane
Recipients brett.cannon, dino.viehland, eric.snow, methane, serhiy.storchaka
Date 2019-05-30.23:27:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1559258840.88.0.136945551949.issue36839@roundup.psfhosted.org>
In-reply-to
Content
> In the Instagram case there's about 20mb of byte code total and there are 3-4 dozen worker processes running per server.  The byte code also represents the second largest section of memory as far as serialized code objects are concerned, the only larger one is strings (which are about 25mb).  

How did you measure it?  How much % of the RAM usage of process?  What "serialized code objects are concerned" means?  Don't you concern RAM usage in process?


> FWIW, I don't see the problem with supporting any read-only "buffer" object, rather than just bytes objects, for the string of bytes in a code object.  That's all that Dino is proposing.

It means byte code is changed in anytime by anyone other than code object.
code object is not immutable anymore.  "read-only" means only code object doesn't change the co_code.  Anyone else can modify it without breaking Python (and Python/C API) semantics.

For example, per-opcode cache can't assume opcode is not changed.
I think there are some other possible optimization from co_code is constant.

Another complexity is GC.  We allowed only bytes here (no subclass allowed) and it allow us to code object is non-GC object.

If we allow any object implementing buffer protocol, we should make code object as GC object.  We can untrack the code object if co_code is bytes (like tuples does), but all code objects needs 16byte header (like tuples requires it...)

Of course we can break the rule and allow Python makes circular reference not collected.

But please don't think changing from bytes to arbitrary objects is simple change.

I think it needs significant benefits for typical users, not only for Instagram.
If only Instagram get benefit from this, keep it as Instagram's internal patch.
History
Date User Action Args
2019-05-30 23:27:20methanesetrecipients: + methane, brett.cannon, dino.viehland, eric.snow, serhiy.storchaka
2019-05-30 23:27:20methanesetmessageid: <1559258840.88.0.136945551949.issue36839@roundup.psfhosted.org>
2019-05-30 23:27:20methanelinkissue36839 messages
2019-05-30 23:27:20methanecreate