I just did some experiments and measured the time it takes to update a display, so lots of i2c operations involved. I got a 1.6x speed-up by removing the asserts (RELEASE=1). [Update: the next sentence is incorrect, see next post] The esp8266 clock rate (80 vs 160 Mhz) has almost no effect because I'm pretty sure the execution rate is dominated by flash speed (another reason not to use the esp-01 modules 'cause they have a 40Mhz flash chip).
Switching from -Os to -O1 makes the firmware bigger and slower. Switching from -Os to -O2 makes the firmware too big. Switching -DLINK_TIME_OPTIMIZATION on, which really just adds force-inlining pragmas in jsutils makes the firmware bigger and slower. It turns out that -Os has all the optimizations of -O2 that don't tend to increase code size. So the bottom line is that GCC seems to be the smartest about what to inline and what not to...
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I just did some experiments and measured the time it takes to update a display, so lots of i2c operations involved. I got a 1.6x speed-up by removing the asserts (RELEASE=1). [Update: the next sentence is incorrect, see next post] The esp8266 clock rate (80 vs 160 Mhz) has almost no effect because I'm pretty sure the execution rate is dominated by flash speed (another reason not to use the esp-01 modules 'cause they have a 40Mhz flash chip).
Switching from -Os to -O1 makes the firmware bigger and slower. Switching from -Os to -O2 makes the firmware too big. Switching -DLINK_TIME_OPTIMIZATION on, which really just adds force-inlining pragmas in jsutils makes the firmware bigger and slower. It turns out that -Os has all the optimizations of -O2 that don't tend to increase code size. So the bottom line is that GCC seems to be the smartest about what to inline and what not to...
(I want to run some of the benchmarks too)