Why not manage access to such things in a singleton class?
Why not manage access to such things in a singleton class?
We had a decent sized library at a previous company that pulled in modules that defined huge register maps, wrapped c++ libraries, etc.
I wrapped all imports in a lazy importer that was triggered by the first attribute access. It brought our script startup times from 3 seconds down to a fraction.
Blows me away that this isn't default behavior for ALL modules.
You could I suppose do some cache warming to make sure the first user request isn't slowed down, but its one more thing to think about.
Well, putting code in the root of your file is generally the problem to such things, I would argue. Granted, I don't know about how that is necessary when it comes to "register maps" and "wrapped c++ libraries". But I'd imagine you should be encapsulating them away anyways and that would include fixing large startup time by design.
If you want hundreds on megs of shared mutable state, a database is a proper solution.
I'd like the program to finish in 15 seconds or less, please.
The train of the discussion, if you go and read the OP's link and inner links, is like this:
- Singletons are bad - Why are singletons bad? - They're not "real" OO, they're global state, they obfuscate dependency, etc, etc, etc - But what if I just legitimately have a ton of global state? - Use a database! Use a filesystem!
The last point in the chain admits that the first point is mistaken. "Use a database" is just saying "use someone else's code to solve your problem". What if the database is implemented using singletons? What if it uses code that isn't OO at all? All you've accomplished is to say "OO can't solve your problem, use something external". In fact, my problem is solved just fine by using a singleton.
immutable singleton is fine. The other concern is performance, but if you don't have to do this, there is no point.