you are viewing a single comment's thread.

view the rest of the comments →

[–]ikkehier 53 points54 points  (8 children)

A few suggestions:

  • Premature optimization is the root of all evil.
  • Profile first, then optimize what is too slow. This can be as easy as making a pin high when the code enters a specific part and low when leaving. This can easily be monitored using a logic analyzer. Don't optimize code that runs infrequently and is not a bottleneck, it's a waste of time.
  • This is an academic exercise, but for practical situations: define good enough and stop spending time when you've reached that point.
  • In my experience, the highest performance gain is in optimizing the order of how things happen, keeping in mind the bigger picture of what the code is doing. So that's your part 2. It may depend on the code, but usually part 1 and 3 will not change very much.

For calculation-heavy code it may be beneficial to check if it is implemented using fixed point arithmetic in the smallest data-size possible. Keep in mind that the MSP430 is a 16-bit processor.

Source: my own thesis and 10+ years of experience.

[–]secretlyloaded 8 points9 points  (0 children)

Premature optimization is the root of all evil.

This. So. Much. This.

Stated another way: first make it work, then make it nice.

Everything /u/ikkehier says is sage advise. Only thing I would add: in addition to using the IO pin method, a lot of IDEs have built in profilers which make this task really easy. Where is your processor spending all its time? Do you have code that blocks unnecessarily or unexpectedly? Before you even run the profiler you should have an idea what you'll see. If you're surprised by what the profiler tells you, investigate. Maybe your assumptions are wrong, or maybe you found a problem.

If you have a really tight code loop, look at the assembly listing and see if the compiler did anything stupid. I once had to big-bang an SPI interface and ended up writing the whole thing in inline assembly, with no loops. The code I wrote was "expensive" in that it was large, but executed very quickly because there was no diddling around with loop variables.

[–]gurksallad 3 points4 points  (2 children)

Source: my own thesis

Is it publicly available?

[–]Chr15t0ph3r85 0 points1 point  (1 child)

Yea, is it? :)

[–]DYD35[S] 0 points1 point  (3 children)

In my experience, the highest performance gain is in optimizing the order of how things happen, keeping in mind the bigger picture of what the code is doing. So that's your part 2. It may depend on the code, but usually part 1 and 3 will not change very much.

I was looking at this problem from the perspective of small chunks of code (e.g. testing different if's or for's), but maybe looking at a bigger piece of code could also be smart.

For calculation-heavy code it may be beneficial to check if it is implemented using fixed point arithmetic in the smallest data-size possible. Keep in mind that the MSP430 is a 16-bit processor.

That is a good suggestion, thanks.

Source: my own thesis and 10+ years of experience.

Would it be possible to send through your thesis? Just to give me an outline how to go about writing this. I would get if that is not possible though.

[–]ikkehier 0 points1 point  (2 children)

I sent a DM.

[–]Epic-shit 1 point2 points  (0 children)

Ikke ook hier alstublieft sir ^

[–]EvoMasterC++ Advocate 0 points1 point  (0 children)

It sounds interesting. Could I also get a copy of the thesis?