4 ms·
it is often better to go ahead and do an operation, then choose to inhibit or ignore some or all of the results, than try to conditionally perform the operation
by cygx 12y ago
it is often better to go ahead and do an operation, then choose to inhibit or ignore some or all of the results, than try to conditionally perform the operation.
The way we have traditionally measured performance and optimized our games encouraged a lot of conditional operations [...] This gives better demo timing numbers, but a huge amount of bugs are generated because skipping the expensive operation also usually skips some other state updating that turns out to be needed elsewhere.
Now that we are firmly decided on a 60hz game, worst case performance is more important than average case performance, so highly variable performance should be looked down on even more.
Two words: Battery life. In case of mobile devices, this is not sound advice.
- nkurz 12y agoIs this covered by the update in John's introduction? To make things more complicated, the .do always, then inhibit or ignore. strategy, while a very good idea for high reliability systems, is less appropriate in power and thermal constrained environments like mobile. Or do I misunderstand your objection?
- cygx 12y agoNo, you're completely right - I only skimmed the addendum. In fact, I actually only skipped that particular paragraph - Murphy's law strikes again :( It's just that two days ago, I had to deal with exactly that issue, so it was fresh on my mind while reading the article...
- ufo 12y agoLooks like Carmack was right then. Conditional paragraph execution does lead to extra bugs :)
- uzfzjvzjftzdtz 12y agoHe states the same on that very web page.