Monkey C compiler optimization settings?

That's one reason why it's worth to try Prettier Monkey C optimizer, because it can optimize some things for old devices (that really need it) that the Garmin compiler doesn't do. Or at least didn't do in the past. I wouldn't be surprised if they were also looking at Prettier and copying some ideas into the newer versions of the compiler.

jim_m_58 said:

The best optimizer is located between the chair and the keyboard, and things depend on how well the the original code was written.  If the code isn't that great, the optimizer could really help, but well written, maybe not as much.

Counterpoint - if no optimizer is available or optimization is disabled then:

- well-written [*] code is usually not optimal by default (especially in terms of memory/space)

[*] (as in code that follows best practices, is maintainable, is easy to read/understand, makes full use of language features, etc.) 

- optimizing by hand (e.g. for space) can result in really ugly code that's hard to maintain or read, and really isn't suitable for sharing (or for team development).

See all the old threads about saving memory by using anti-patterns like replacing enums/constants with their values, replacing short or rarely-called functions with their implementations (i.e. "manual inlining" of functions), avoiding the use of dictionaries and switch statements, etc. Some of these recommendations (like avoiding the use of dictionaries and switch statements) may still be relevant even when compiler optimization is enabled, but that doesn't mean that avoiding the use of dictionaries and switch statements is necessarily "better" code (it's just more "optimal" in terms of space).

So on the contrary, if you write "good" [*] code you may find that the result is the opposite of optimized - it's actually bloated.

Therefore, I think having a built-in optimizer in the compiler is really important if the goal is to write "good" code (that's maintainable and/or shareable) *and* also optimize for space or speed. But yeah, even with a good optimizer, you may still be able to save more memory by optimizing certain things by hand (e.g. avoid the use of dictionaries). it's arguable that these manual optimizations don't necessarily make the code "better" tho (I guess it all depends on what you mean by "good" code).

Even when writing C, which is as close to the bare metal as you get without writing assembly, I think most people would prefer to use the built-in compiler optimization options rather than to rely on hand optimizing code, unless optimal speed/size is a vital concern.

As a concrete example, before the Monkey C optimizer existed, it was often recommended in the forums to manually replace enums with their values in order to save memory. I personally did this for data fields that ran on old devices, and saved memory by using this technique (among others). (Not that it matters, but I was one of the ones who recommended this practice, although I recognize it's an anti-pattern).

But nobody would say that manually replacing enums with their values is a "best practice" or results in "good code", even if you put the enum in a comment next to the value (so the reader knows what the value corresponds to).

On the contrary, most people would say the use of magic numbers in code is an anti-pattern and should be avoided at all costs.

Now that the Monkey C optimizer can replace enums and constants with their values, we can have our cake and eat it too (at least for that one optimization).

So actually, there is a least one kind of optimization which is better left to the compiler as opposed to the developer, if only because the manual version of this optimization makes the source code worse.

FlowState said:

- well-written [*] code is usually not optimal by default (especially in terms of memory/space)

That depends on the experience of the programmer with both the language and the environment.