Derive performance impact from binary size

Question

I'm working on an electronic project. In the project I've got a microcontroller. I would like to measure the impact in terms of time performance of my changes.

The binary is not huge (11760 bytes actually). The micro-controller run around 20Mhz (based on the crystal value). So basically he can run 20M operation per seconds.

Do you think it's a good idea to check the performance impact due to changes based on the count of instructions per functions ? Something like :

enter image description here

score 6 · Answer 1 · answered Jan 01 '14 at 12:25

It seems that you're confusing static instruction vs dynamic instruction counts.

The size of a function or the binary doesn't say how many instructions it would run. Take for example a simple loop which translates (in some pseudo assembly I made up) into

    mov r1, 100
label1:
    dec r1
    jnz label1

These are 3 static instructions, and would take up some small space on the binary (depending on their opcode sizes), but the processor running it would have to perform the loop 100 times, amounting to 201 dynamic instructions. The performance, of course, depends on the number of dynamic instructions executed (plus any delays caused for example by bubbles, mispredictions, pipe depth, etc..).

If for e.g you were to replace 100 with 10000, you'd take exactly the same space on the binary (assuming 100 was stored as an int to begin with), but the execution would probably become 100x slower.

Right. The way to determine performance of code is to either analyze it intensively by hand or to measure it. The latter's usually a better bet, especially when optimizing compilers are involved. For larger bodies of code, performance analysis tools -- which can tell you _where_ the time is being spent -- are a lifesaver. Remember that infinite speedup of something that's only consuming 1% of runtime is only a 1% overall speedup. You need deep understanding of where your code is spending time when processing real-world data, or you're likely to waste time optimizing the wrong things. — keshlam, Jan 01 '14 at 12:46

score 2 · Accepted Answer · edited May 23 '17 at 12:22

Program size and program speed are not directly related.

I've done what you are doing - programming a microcontroller and wanting to make it as fast as possible.

First I get the program working, doing what is necessary.

Then I wrap a temporary loop around it, so it repeats its work endlessly, or for a long time.

While it is running, I manually interrupt it under a debugger or emulator, and then examine the call stack and any other variables as needed.
My object is to understand, in complete detail, why it was spending that moment in time.

I repeat this several times, like 10 times.

From those 10 samples, I look to see if there's any activity present on more than 1 of them that I could eliminate or make shorter. For example, if I see on 4 of those samples that there is a function being called, from a particular place, and if I can think of a way to avoid that call most of the time, doing so would save about 40% of the execution time. That's a speedup of 1/(1-0.4) = 1/0.6 = 1.67 = 67%, give or take. That's a serious speedup.

You see, if there's anything you can do to make the code run faster, this technique will find it.

It is different from the usual advice to "measure, measure". All measuring does is tell you that if a routine doesn't take much inclusive time, you should look elsewhere.

Measuring tells where you should not look, but, in all but toy programs, it is very unspecific about where you should look. (People sometimes take this as good news, as if failing to find a way to speed up their program implies there is none :)

The interrupting technique pinpoints problems.

Derive performance impact from binary size

2 Answers2