Re: sparse components
Megan Fox <[email protected]>
| Newsgroups | gmane.games.devel.sweng |
|---|---|
| Message-ID | <[email protected]> |
> This is my experience exactly, and it seems to hold true throughout software > development. It's really, really easy to think you have "The Answer" to > making some slippery problem generic, whether it be a generic tool, data > format, architecture paradigm, data structure, language feature, etc. Then > you try it and it blows up in your face, while the simple naive solution > works and lets you get on with the real problems. You know you have some > great, reusable code going when it's utterly boring and trivial to think > about. While that's true, it often ends you in a position where you've coded half your systems to be dependent on slippery (but convenient and logical and handy) virtual function relationships such that optimizing them out is near impossible, and cache misses are hanging you out to dry, then you're well and truly dead short of a very difficult scramble... that could have been avoided by simply doing a bit of smart forecasting wrt. performance and writing up a short little document on coding standards for your new hires. I agree that over-optimization too early leads to spaghetti-style special casing all over the place, but to ignore it early on is, arguably, even worse. The one way, you have inconvenient code (and have forecast your schedule to account for whatever lack of productivity that creates), but if you go the other route, you may well end yourself in a problem that can not even remotely be fixed within whatever time remains. The final performance impact of ignoring it entirely in favour of convenience and logical code design is far, far more difficult to predict. Between the two, especially if you're dealing with a new platform for instance, I would argue that over-optimization too early (to whatever point can fit within your schedule) is the safest bet. Not ideal, of course - ideal is that you're solving a problem you've solved before, and already know an optimal solution that balances speed vs reuse et al - but the less risky of the two mindsets when a binary decision must be made. -- Megan Fox http://www.shalinor.com/ _______________________________________________ Sweng-Gamedev mailing list [email protected] http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com