CIQ Simulator Stats (Profiler / Mem Usage) - How useful and reliable are these tools in comparing older vs newer models?

Can someone kindly help me understand how to navigate these tools, their information, and the difference between older and newer watch models?

For the same watch face code, according to the Profiler, an onUpdate() call yields an average time of 70,000 (us) on a Fenix 7 Pro, and that's significantly higher than the 40,000 (us) on a Fenix 6 Pro. Shouldn't it be the other way around?

As for the memory usage stats, peak memory is at 99KB for the Fenix 6 Pro and 45KB for the Fenix 7 Pro. What's behind this difference?

Thanks,

Top Replies

flocsy🤠 4 days ago in reply to the-ninth +1

markw65 is usually fixing these quickly (so it's worth to open a bug report, i.e an issue on GitHub) and for the riskier features there are switches in the settings. However you're right, there is some…

All Replies

flocsy🤠 5 days ago in reply to the-ninth

Do you have the Post build PRE enabled? Basically I think the default was pretty good, and I did enable the rest (some of the optimizations were opt-in), so just enable everything and test it.

jim_m_58 5 days ago

The f7 uses the graphics pool and the f6 doesn't. If you have bitmaps or custom fonts, and based on what they are, could explain the memory difference.

Without the graphics pool, those things are stored in the apps memory, not in the pool

FlowState 4 days ago in reply to jim_m_58

jim_m_58 said:
The f7 uses the graphics pool and the f6 doesn't.

It's the OP (from 2023) who asked about f6 vs f7 and you already explained that (in 2023).

The poster who restarted this discussion 1 day ago asked about Fenix 6 vs Epix 2 Pro and already quoted what you said about the graphics pool (so they're aware of it too).

Idk sometimes I kinda get why most forums or similar communities (reddit) close threads after a few months or so. (I also see the case for keeping certain types of threads of open forever, but ofc there's no good way to tell the difference.)

the-ninth 4 days ago in reply to flocsy🤠

flocsy🤠 said:
Do you have the Post build PRE enabled? Basically I think the default was pretty good, and I did enable the rest (some of the optimizations were opt-in), so just enable everything and test it.

Without doing any deeper tests, I stumbled on one feature in my app that does not work anymore when I compile with the Prettier Extension. Still have to look into what causes this, but I am a bit wary about what other hidden bugs may be introduced by using the Extension.

flocsy🤠 4 days ago in reply to the-ninth

markw65 is usually fixing these quickly (so it's worth to open a bug report, i.e an issue on GitHub) and for the riskier features there are switches in the settings. However you're right, there is some level of risk involved. For me the features I was able to squeeze in outweigh these risks. I had sometimes waited a few days before a fix came and only after I released my production app.

Another thing I sometimes do is looking at the optimized code and learn tricks from it, so my unoptimized code also improves with time.