Inada Naoki <songofaca...@gmail.com> added the comment:
On Sat, Jun 1, 2019 at 2:47 AM Brett Cannon <rep...@bugs.python.org> wrote: > > Brett Cannon <br...@python.org> added the comment: > > RE: "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." > > But who's typical in this case? You? Me? We're talking code objects, > something that the typical Python user doesn't even know exists if you take > "typical" to mean "common" or "majority". I suspect if we asked Python > developers if they knew what lnotab was an abbreviation of they wouldn't > know, let alone how it worked. > > And just because Instagram did this work and is making it public doesn't mean > (a) others wouldn't use it or (b) others are already doing it privately. > There are plenty of other companies with massive server installs of Python > beyond Instagram. > > My point is we have to be very careful when we start to claim we know what is > typical or useful to the wider community considering how huge and diverse the > Python community is. > I'm sorry for bad word choice. I didn't mean "majority" or "common". For example, I was +1 for gc.freeze(), even if majority users doesn't use it. My point is (a) it's very hard others utilize it, and (b) it's very hard others confirm the benefit. And I suspect that Dino's estimation is wrong, but no one can verify the estimation because he didn't show enough concrete information. Elaborately speaking, * They need to use custom importer and serializer other than marshal to import code objects. * They need to use lightweight object for buffer. At least, memoryview object is large (192byte on Python 3.7.3 amd64). Even if Instaram can not open source their import system, they can be show more concrete data. For example, their this [1] report is very good at considering gc.freeze(). [1] https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172 While I agree that mmap pyc files is interesting idea, I feel allowing buffer object for co_code is wrong way to achieve it (*). But there are no enough data to discuss the benefit. Current status is Dino claims this idea have benefit in Instagram, but no one can confirm the benefit. I think we shouldn't discuss without reliable or reproducible data for this type of proposal. (*) One possible idea is code object have just a pointer and length for co_code, and reference to object who owns the data (mmaped file). code object can load co_lnotab and docstring lazily too. ---------- _______________________________________ 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