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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.