first of all, I don't use Arduino a lot. I just like eclipse more than the Arduino IDE, and i always had my own "libs" which I copy/paste if needed.
However I am currently programming something computationally intensive (AHRS) and after finishing my first optimized version i tested the performace on it.
It took my Atmega about 9ms to calculate. (compiled and linked in eclipse, with the latest winavr)
I was curious about the performance of a other (Arduio-based, in my eyes not optimized at all) Code i found on the internet.
It took him 3ms to calculate basically the same. Both used floats.
So i wrote a little test programm. 30k runs: 2 float add, and 2 mulitply.
It took the in arduino compiled code 645ms
The one i compiled in eclipse needed 3933ms
both codes sum up integers at the same speed, so neither of them has timers in background that take too much processing power.
I tried the same compile arguments as arduino uses, but i couldn't get any improvements.
EDIT: funny enough the arduino AHRS-code ported to eclipse takes 17ms to calculate.
Can you post the size of the programs here as well? Also, how did you measure the time it took to complete the calculations? Did you write a pin to one and back to zero at the end of the calculations and measured with an oscilloscope? Used millis()? Serial Port?
I measured with millis( ) but to clearify I let my uC send 2 chars wire the serial interface and measured the time on the computer.
Optimization settings where exactly the same.
I finally figured it out. Arduino links with the C linker (avr-gcc), Eclipse by default with c++ (avr-g++).
I haven't thought that the linker would make that much of a difference. Maybe the libs he links with do.
Thanks for you help anyways, i know I'm sometimes not a enjoyable questioner.
The difference in timing is quite large and I still suspect an optimization is taking 90% of the guts out of your main loop. I would be interested to see what happens if 'a' and 'b' have a 'volatile' storage class. I would predict the timings would be more in line with one another.
The underlying AVR-LIBC in the two cases is probably a different version, but not significantly different so as to contain a whole different float implementation.