On 2/21/22 22:06, Chris Angelico wrote:
On Mon, 21 Feb 2022 at 16:47, Larry Hastings<la...@hastings.org> wrote:
While I don't think it's fine to play devil's advocate, given the choice between "this will
help a common production use-case" (pre-fork servers) and "this could hurt a hypothetical
production use case" (long-running applications that reload modules enough times this could
waste a significant amount of memory), I think the former is more important.
Can the cost be mitigated by reusing immortal objects? So, for
instance, a module-level constant of 60*60*24*365 might be made
immortal, meaning it doesn't get disposed of with the module, but if
the module gets reloaded, no *additional* object would be created.
I'm assuming here that any/all objects unmarshalled with the module
can indeed be shared in this way. If that isn't always true, then that
would reduce the savings here.
It could, but we don't have any general-purpose mechanism for that. We
have "interned strings" and "small ints", but we don't have e.g.
"interned tuples" or "frequently-used large ints and floats".
That said, in this hypothetical scenario wherein someone is constantly
reloading modules but we also have immortal objects, maybe someone could
write a smart reloader that lets them somehow propagate existing
immortal objects to the new module. It wouldn't even have to be that
sophisticated, just some sort of hook into the marshal step combined
with a per-module persistent cache of unmarshalled constants.
//arry/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/UN3BIEHDK2CCL563MSIJ4DXDWOWHNKHR/
Code of Conduct: http://python.org/psf/codeofconduct/
