
On 2/21/22 22:06, Chris Angelico wrote:
On Mon, 21 Feb 2022 at 16:47, Larry Hastings<larry@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/