On Tue, 22 Feb 2022 at 03:00, Larry Hastings <la...@hastings.org> wrote: > > > 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. >
Fair enough. Since only immortal objects would affect this, it may be possible for the smart reloader to simply be told of all new immortals, and it can then intern things itself. IMO that strengthens the argument that prefork servers are a more significant use-case than reloading, without necessarily compromising the rarer case. Thanks for the explanation. ChrisA _______________________________________________ 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/3D436RCMHODEIBVDIWIJLKZU2TGHBE4J/ Code of Conduct: http://python.org/psf/codeofconduct/
