optimization of embedded resources

misterT said:

That's why I said fixed point.

Click to expand...

Something with my eyes. I would swear I saw "floating".

misterT said:

Ian used to be strict about off-topic.. what happened ?

Click to expand...

It's not "Off Topic"... the thread is about optimization.... I believe the comments so far are relevant..

Ian Rogers said:

If he's anything like me... I always have the resource usage manager in view..

Click to expand...

Please forgive the interruption. May I ask which IDE you're using, and, if MPLAB, where the resource usage manager is, please?

TIA. Cheerful regards, Mike

Mike - K8LH said:

Please forgive the interruption. May I ask which IDE you're using, and, if MPLAB, where the resource usage manager is, please?

TIA. Cheerful regards, Mike

Click to expand...

You are welcome to jump in anytime..

Its not really the resource manager.... Its the memory usage manager/ Gauge... ( It's probably the only resource we use on Pic's anyway ).

misterT said:

Anyway.. has anybody even tested how much larger your code gets when optimizing for speed. Or how much faster your code gets when optimizing for speed. I have, the difference between size/speed is usually irrelevant, and the selection between optimization levels is more psychological than practical (when compiling for the "final product", debugging is different case).

Click to expand...

Back at work from two week holiday. I quickly compiled my current project with -Os and -O3.

-O3 tries to optimize code very heavily for performance. It includes all of the optimizations -O2 includes, plus some more.
-Os, on the other hand, instructs GCC to "optimize for size." It enables all -O2 optimizations which do not increase the size of the executable, and then it also toggles some optimization flags to further reduce executable size.

Click to expand...

results:
O3: 13794 bytes
Os: 10076 bytes

The difference is more significant than I expected. I did not measure any performance yet. I'll post here if I do some more testing.

I have an elaborate I2C library which has lots of small functions. I think most of the optimization involves inlining those small functions... which is kind of useless on a blocking I2C communication. Only wastes memory.