Inada Naoki <songofaca...@gmail.com> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36839> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
