"Is This Faster?" Issue #1

This is a very important point.

I don’t know how much time I’ve spent optimizing things for no apparent reason, other than to “do it”.

“Premature optimization is the root of all evil”. This saying is very very true.

i knew i shouldn’t have replied  ;)  i’m not here to defend pointless optimization

all true, and i’ve read them all 1000 times before, and i’ve already agreed above.

but a “tight loop” scenario as you say is exactly the example i was attempting to describe

ok, devil’s advocate (since the can of worms is already opened, why not?)

on the flip side, there is no evil in following best-practices in advance simply because you’re worried that you might be optimizing too soon – it’s not like typing "local"in front of a variable is a radical idea.  it takes 1 second to implement and is a well-known language feature that has the neat benefit of being faster than not doing so.  (not to mention that it’s just better practice in general to declare local things local)

@All,

We’re not quite there yet, but lest this turn into a holy war…let me re-iterate my initial statement

Hi.  First, this is not a question.  Instead I’m posting the results of some ( perhaps silly ) questions that were floating around in the back of my mind.  

This was just me making a post about some ideas I found interesting.  

I am firmly of the mind:

  1. Always try to use performant coding practices, BUT…
  2. Don’t do so at the expense of code legibility and portability, AND…
  3. Don’t optimize until you need to, AND THEN…
  4. Only optimize what you find to be the worst performer via profiling.

Cheers,

Ed

My response wasn’t aimed at you, just a general comment :slight_smile:

I agree with what you just said 100%.

My take on this is that its good to have best practices which will help keep you from getting into some situations where optimization is required.  Avoiding those pitfalls is a good thing.

On the other hand, things like multiplying by 0.5 vs. dividing by 2 is frequently an optimization does more harm than good.  While no one would argue that CPU wise, a multiply operation is faster than a divide, it’s more typing and frankly harder to read.  And if you’re doing something like:

local cx = display.contentWidth * 0.5

at the top of your code and then using cx everywhere else, then really, you saved 2 CPU cycles that only happens once in your code.  Sure in a tight loop, you need to use multiplies over divides (I’m using this as an example) but it’s pointless when the optimization is hit once and never again.

To me, where you need to be spending time is optimizing your images and audio.  Keep the images the right size for the device (i.e. don’t load in huge images and force Corona SDK to scale them down for you on smaller screen).  Think about texture memory bounderies: don’t have a 1025 pixel wide image.  Find a way to make it 1024.

Follow best programming practices and things should do a great job of taking care of themselves.

But that said, when you do start having issues, profile, and look for optimizations.

Rob