SDK 8.2.1: Move constant folding of has checks with API functions to the -p optimization level

The changelog says "constant folding of has checks with API functions", not simply "constant folding".

My understanding:

1) constant folding: replacing constants with their values at compile-time

2) constant folding of has checks with API functions: replacing has checks related to API functions [*] with their values at compile-time. In other words, this is the feature related to "--disable-api-has-check-removal"

[*] and, apparently, enums like Activity.SPORT_*. Probably class members as well. Maybe "API functions" isn't the best term here.

Yes, it's unfortunate that Garmin decided to describe both 1) and 2) with the phrase "constant folding". But I think that line of the changelog only refers to 2) and not 1).

It makes sense to me why 2) would be classified as a performance optimization - as others have pointed out in the past, has checks are relatively expensive. This is why some people have suggested performing certain API-related has checks at init time, rather than executing them over and over again.

So then unless I use -O Np then the has check is runtime only? And --disable-api-has-check-removal is effective if we use 'p' on the optimization mode?

That's what it looks like.

I was playing with has checks for the recent Activity sport/subsport bug report, and API has checks were not removed with the default optimization level (nor if I chose a level from the drop-down in the settings, like "Fast").

When I set the "-O3p" compiler option, API has checks were removed. And yes, --disable-api-has-check-removal still disables this behaviour.

(I can also confirm that API has check removal does work with Activity.SPORT_*, although it doesn't work *properly*, due to the fact that the compiler / device file / sim don't "know" that old devices like fenix5plus lack support for things like Activity.SPORT_MEDITATION.)

Also, I know that many people (including me) have suggested that API has check removal should be disabled by default, because it always causes issues that are hard to anticipate / diagnose if you're not familiar with the feature. And it can cause old code which used to work (without optimization) to suddenly stop working. It could be argued that it violates the principle of least surprise.

So it looks like Garmin has actually given us what we want, which is great!

Same with the new data field setup flow, which asks users to associate a newly installed CIQ data field with activities. How many times have CIQ devs complained that users have no idea how to add data fields to an activity? 

At least Garmin is trying to improve things. Unfortunately CIQ is 10 years old at this point....

FlowState said:

It makes sense to me why 2) would be classified as a performance optimization

On further reflection, I think the real reason this change was made was simply to arrange for "API has check removal" to be disabled by default, without having to create a new compiler option to explicitly enable it.

The fact that API has check removal is a legit performance optimization is probably not the main reason this change was made.

flocsy🤠 said:

I would've preferred an explicit compiler option than doing it this way

That's fair, but I guess this was more expedient. It will have the desired effect by default, which will fix the problem for 99% of devs.

Except that they removed an existing feature from more than half of the apps: apps that use z or don't use optimization. And even worse , there's no way to add it back, except changing from z to P that obviously will have side effects, especially for datafields that already are close to the memory limit

flocsy🤠 said:

Except that they removed an existing feature from more than half of the apps: apps that use z

Yeah, I get it.

My point is that Garmin probably decided this wasn't the best feature in the world after all, and they're willing to make it unavailable for people who don't use performance optimization. You can always make a feature request for a flag to specifically enable this type of optimization.

Again, this behaviour has caused problems for devs over and over again, and more than one dev has mentioned that it would be better to be off by default, so I think I understand why Garmin did what they did.

flocsy🤠 said:

or don't use optimization.

But API has check removal has always been an optimization afaik. I wouldn't expect it to work if optimization is disabled.

https://developer.garmin.com/connect-iq/monkey-c/compiler-options/

FlowState said:

I wouldn't expect it to work if optimization is disabled

That's fine, but I do have 3z