Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualKhatharr

Posted 30 December 2012 - 04:19 PM

Aye, some guru once said something like, "The fastest and most error free code is that code which is never written."

The idea being that reducing work by having good structure is very nearly always better than optimizing the individual routines. In production code it's almost a sin to try and low-level optimize something that a profiler hasn't singled out and can't be refactored out. If you're getting paid to code something and you spend 5 hours on an optimization that gets factored out the next day you just wasted 5 hours of paid work. Sometimes I'll get 'the bug' (in my brain) and optimize something until it's ridiculous, but I always do so knowing that it's a pointless exercise, and I usually think up several ways to factor the code out even while I'm in the midst of my madness.

I posted something a while ago about an xor encryptor that I was playing with (it was making my hard disk stall and make a weird grinding noise). I optimized it by actually compiling bytecode for the encryption at runtime and then executing it, which is ridiculously fast, but the fact is that the choke-point in that app is the disk IO. I knew from the start that if I were to run the old (non-optimized) code while the app was async reading into the next buffer it would completely mask the encryption time, resulting in better performance without the tomfoolery. I just wanted to play with assembly for a while.

#4Khatharr

Posted 30 December 2012 - 04:18 PM

<p>Aye, some guru once said something like, &quot;The fastest and most error free code is that code which is never written.&quot;<br />
<br />
The idea being that reducing work by having good structure is very nearly always better than optimizing the individual routines. In production code it's almost a sin to try and low-level optimize something that a profiler hasn't singled out and can't be refactored out. If you're getting paid to code something and you spend 5 hours on an optimization that gets factored out the next day you just wasted 5 hours of paid work. Sometimes I'll get 'the bug' (in my brain) and optimize something until it's ridiculous, but I always do so knowing that it's a pointless exercise, and I usually think up several ways to factor the code out even while I'm in the midst of my madness.</p>
<p>&nbsp;</p>
<p>I posted something a while ago about an xor encryptor that I was playing with (it was making my hard disk stall and make a weird grinding noise). I optimized it by actually compiling bytecode for the encryption at runtime and then executing it, which is ridiculously fast, but the fact is that the choke-point in that app is the disk IO. I knew from the start that if I were to run the old (non-optimized) code while the app was async reading into the next buffer it would completely mask the encryption time, resulting in better performance without the tomfoolery.</p>

#3Khatharr

Posted 30 December 2012 - 04:11 PM

Aye, some guru once said something like, "The fastest and most error free code is that code which is never written."

The idea being that reducing work by having good structure is very nearly always better than optimizing the individual routines. In production code it's almost a sin to try and low-level optimize something that a profiler hasn't singled out and can't be refactored out.

#2Khatharr

Posted 30 December 2012 - 04:11 PM

<p>Aye, some guru once said something like, &quot;The fastest and most error free code is that code which is never written.&quot;</p>
<p>&nbsp;</p>
<p>The idea being that reducing work by having good structure is very nearly always better than optimizing the individual routines. In production code it's almost a sin to try and low-level optimize something that a profiler hasn't singled out and can't be refactored out.</p>

#1Khatharr

Posted 30 December 2012 - 04:08 PM

Aye, some guru once said something like, "The fastest and most error free code is that code which is never written."


PARTNERS