If SDK 7 can compile out unused branches with the has check, why are binaries with it still consistently larger?

As a sanity check, I limited the device in manifest.xml to only support one device (enduro 3), only use one "has" check, and compile with the check totally commented out and with it uncommented, and the binaries are consistently a different size, by about 30 bytes.

This is the check:

function getInitialView() as [Views] or [Views, InputDelegates] {
if (Toybox has :Complications) {
return [ new WfView(), new WfDeligate() ];
} else {
return [ new WfView() ];
}
}

And this is it commented out

function getInitialView() as [Views] or [Views, InputDelegates] {
//if (Toybox has :Complications) {
return [ new WfView(), new WfDeligate() ];
//} else {
//return [ new WfView() ];
//}
}

The first one consistently generates a binary .iq file that's 30 bytes bigger when I export the project. Shouldn't they be identical, if the alternative branch gets compiled out?

Top Replies

All Replies

0 jim_m_58 27 days ago

re you using the -disable-api-has-check-removal compiler flag? That allows the has check to be done at run time and not compile time, which I prefer. For cases where a device may have newer FW than the minimum FW defined for CIQ. A case of this was when System 7 FW was out in beta, but many users still had System 6

0 jerry123 27 days ago in reply to jim_m_58

No, I had thought of that but made sure I'm not using it, unless it could get set somewhere other than manifest.xml, monkey.jungle, or the vscode monkeyc extensions?

0 jim_m_58 27 days ago in reply to jerry123

Maybe the optimization level is involved. But at the same time a 30 byte difference isn't really that big a deal.

0 jerry123 27 days ago in reply to jim_m_58

No, definitely not a huge deal, but this case is only the one spot. I'm trying to figure out whether I should do it for the whole watchface.

I also am coming from a somewhat unique angle, I'm making my watchface to be as power efficient as possible for my personal device, with no settings or anything like that. If the "has" checks add runtime checks for my watch, I'm just going to use a higher sdk level and not support older devices. But, it would be cool if it could support older devices, so that's why I'm even bothering to try

+1 Kyle.ConnectIQ 27 days ago

The compile time removal of has checks requires updated configs which are slowly rolling out. It affects all device configs so as newer devices are updated they'll be updated, and for older devices we'll roll them out in phases.

0 jerry123 27 days ago in reply to Kyle.ConnectIQ

I'm using enduro 3 in this example, is it still waiting on updated configs?

0 FlowState 27 days ago in reply to Kyle.ConnectIQ

Can you clarify whether the compile time removal of has checks depends on whether optimization is enabled or not?

0 Kyle.ConnectIQ 27 days ago in reply to jerry123

yes, it needs the updated configs

0 Kyle.ConnectIQ 27 days ago in reply to FlowState

Yes, at O1 they are constant folded, and at O2 dead branches are eliminated

0 FlowState 27 days ago in reply to jerry123

jerry123 said:
But, it would be cool if it could support older devices, so that's why I'm even bothering to try

The way to do this without optimization / has check removal is to use conditional compilation (via annotations and jungle exclusions) that produces different versions of certain functions for different devices.

Ofc this can be a huge amount of effort compared to simply using has and letting the optimizer do the work for you. If you end up writing 2 or more versions of large functions with very minor differences, it also becomes a maintenance nightmare. Or if you end up creating larger numbers of tiny functions to avoid that, you can also add unwanted overhead to your code.

I actually hacked up a line-by-line C-style conditional compilation system (with #if statements) that works based on a definition file which specifies annotations that are associated with C-style conditional compilation symbols. But it’s still up to the dev to define the exclude annotations in the jungle file. I never did port the auto-build part of the system to VS Code (I originally used it with Eclipse.)

https://forums.garmin.com/developer/connect-iq/f/discussion/7733/solution-for-line-by-line-mc-conditional-compilation