4.1.4 Compiler 2 Beta code size comparsion

I don't use any dictionaries unless I have to, I use very limited classes, if/then/else is more efficient that switch, and direct dc calls are generally more efficient than users layouts.

jim_m_58 said:

I don't use any dictionaries unless I have to, I use very limited classes, if/then/else is more efficient that switch, and direct dc calls are generally more efficient than users layouts.

Yeah, I know but my point is that Monkey C has a bunch of standard features (like classes and dictionaries) which are very expensive to use. Even enums are expensive to use. As per your example, layouts are expensive, but that's just another feature which is supposed to make our lives easier.

So if Garmin were to provide a tutorial on making super-efficient apps, the first thing they would have to say is "please disregard most of the friendly language features we provide", which would be a very confusing message coming from them. If I were a new dev, I would be thinking "why give us all of this stuff if we're not supposed to use it?"

1. I had to change the code that I used with 4.1.4 even to compile with 4.1.4 Compiler 2 Beta (no matter what -O setting). So no, this is 100% not compatible. Until now have you ever upgrade the SDK to the next one and needed to change your code? It's true, once it ran with -O 0 it also ran with -O 2.

2. Yeah, you kicked me out 3 times I think, the good thing is that refreshed the page and "started" to reply again and my previously typed text was there :)

Maybe I'm too optimistic, but this new compiler seems to be one huge step towards optimizing things, so maybe in the not so far future they can also add other optimizations. Like inlining code :) That's not hard to implement and helps readability and even decreases code size. And I'm sure there are lot of other things.

I am seeing a useful reduction using -O2 in Peak Memory from 108.7 down to 102.7 - that's a 6Kb saving on a 124 Kb device. 

(I still have to compile with "-l 0" to ignore the literally hundreds of errors with "-l 1" which I'm still working through!)

Alan.raceQs said:

I suspect that while inlining may improve processing speed, it would be at the expense of memory usage - which is tight enough already! 

As discussed elsewhere, depending on the circumstances, manually inlining code can save a lot of memory.

For example, the following function would be a prime candidate for inlining:

function increment(x) {
  return x + 1;
}

The programmer who wrote that needs to be sent to Siberia for re-educating! 

FlowState said:

As discussed elsewhere

That would make interesting reading, can you post a link please?

Alan.raceQs said:

The programmer who wrote that needs to be sent to Siberia for re-educating!

Haha funny but obviously it's a toy example for the purposes of demonstration. I didn't feel like digging up a meaningful function in my own code which benefited from inlining.

Not to state the obvious, but even the most complex function is a candidate for inlining if it's only ever called once. In modern programming, we usually like to split up huge functions into parts, even if those parts aren't reused multiple times. In Monkey C, sometimes a huge monolithic function has advantages (not for maintainability or readability tho.)

Alan.raceQs said:

That would make interesting reading, can you post a link please?

forums.garmin.com/.../big-update-to-prettier-extension-monkeyc