Creating my object takes too long. Is it bad practice to create a ton of instances at startup to speed things up later?

Question

I have a wizard class that gets used a lot in my program. Unfortunately, the wizard takes a while to load mostly because the GUI framework is very slow. I tried to redesign the wizard class multiple times (like making the object reusable so it only gets created once) but I always hit a brick wall somewhere. So, at this point is it a huge ugly hack to just load 50 instances of this beast into a vector and just pop them off as I use them? That way the delay will only be noticed on startup and run fine thereafter. Too much of a hack? Is such a construct common?

Answer 1

Yes it is bad practice, it breaks RFC2549 standard.

OK ok, I was just kidding. Do whatever is best for your application. It isn't a matter of "hacks" or "standards".

Just make sure you have proper documentation about what isn't as straightforward as it should be (such as hacks).

Trust me, if a 5k investment produced a product with lots of hacks (such as windows), then they [hacks] must really help at some point.

Answer 2

In games, we often first allocate and construct everything needed in a game session. Then we recycle the objects if they have short life-time, trying to get 0 allocations/deallocations while the game session is running.

So no it's not really a hack, it's just good sense to make the computer do less work to get faster. One strategy is "caching", that is, in general, first compute your non-variant data, then run with the dynamic ones. Memory allocation, object constructions, etc have to be prepared before use, where possible and necessary.

Answer 3

Unfortunately, the wizard takes a while to load mostly because the GUI framework is very slow.

Isn't a wizard just a form-based template? Shouldn't that carry essentially no overhead? Find what's slowing the framework down (uncompressed background image?) and fix the root cause.

As a stopgap, you could create the windows in the background and not display them until the user asks. But that's obviously just moving the problem somewhere else. Even if you create them in a background thread at startup, the user's first command might ask for the last wizard and then they have to wait 50x as long… which they'll probably interpret as a crash. At the very least, anticipate and test such corner cases. Also test on a low-RAM setup.