Putting the Nerd in It: Calculating Speedup with Amdahl’s Law

Okay, I promise I will try very hard not to bore you in the next few hundred words. But basically I just want to present a way of determining how much faster a system will be if you speedup one (or more) or its components.

Say that you have an enhancement that can be made to speedup some part of an application.
And say that you know how much runtime you can save with the enhancement.
And say that you know what fraction of the total runtime that part of the application takes up.
Then you can determine how much you will speedup the application as a whole by making that enhancement.

Why is this valuable?

You might be in a situation where you have to justify time and effort spent (and fancy formulas help to dazzle the crowd).
You might have two different enhancements or changes that could be made but only have time to do one. Which should you choose?
You might just want to know how badass your idea really is.

So, I present to you Amdahl’s Law:

Formulas borrowed lovingly from Hennessy + Patterson’s Computer Architecture: A Quantitative Approach

You could use this formula for any other performance metric.  For example, if you were more concerned with memory consumption, the formulas still hold: just replace “runtime” with “memory use” and “speedup” with “memory reduction.”

Hope you find this helpful someday.  I’ll try to keep so many equations out of the next post.

Oh Em Gee, All of Those trace() Statements

Alright, so I saw this insideria.com article by Tyler Larson about conditionally compiling for cleaner Actionscript when it came out and figured that it would be a good idea for peeling out some performance.  And Procrastee McProcrastinator (that’s me) didn’t get a chance to try any kind of pruning yet.

Then tonight as I’m tidying up some code for my side project I see this tweet by Ben Clinkinbeard noting that adding a trace statement increased a loop’s runtime by 1 second.  So following Larson’s article with a little help from flexexamples.com for setting up a flex-config.xml file, I set conditional compiling for every single trace statement and then compiled a new release build.

Wow.  Just wow.  We’re talking seconds shaved off loading batches of images.  And I’m frequently loading these small batches of images so the additional time was just piling up.

I feel incredibly duh-I-should-have-known-that-I-am-such-a-noob.

But hey, live and learn, right?  And I apologize to folks following me on Twitter for the spam and gratuitous face-palming.

Update: Dave Rosenfeld informed me via Twitter that trace actually initiates some disk I/O.  No wonder.

answering those nagging questions about efficient syntax…

This flex application runs small timing tests on variations of syntax in AS3.  Curious as to whether there’s a difference between x++, x+=1, and x = x + 1?  How much does the data type of a for loop’s iterator impact runtime?   Yeah, maybe nitpicking about syntax for performance-sake is overkill in many cases, but for anyone working on data-heavy applications with lots of looping/processing of data, a little can go a long way.