Layout vs 'calculated' UI - performance, battery and memory

So I created a Forerunner 645 lookalike watchface: https://apps.garmin.com/en-US/apps/eaa32b01-2868-4620-93f6-1e689bc5c75a

And I now got 1 or 2 comments about it being 'very slow' on a fenix3, slow as in switching from it to actitivy or widget is taking long (where all this is subjective of course). Now I know that connectiq watchfaces are slower/heavier then the stock garmin ones but I am wondering if there is any way to debug this more...

I switched from a calculated layout (where I simply place items based on screen width, height and shape) to using layout.xml... I know the latter uses some more memory but it helps me control things more. I am wondering if it also has an effect on performance though.

My idea was that switching to layout would be more efficient cpu wise (also after 1 or 2 remarkt about battery usage being a bit high) at the expense of memory but the omments regarding it being slow make me wonder if that is the case.

Is there any more in depth info on all this? Some way to debug or get more insight in cpu and memory usage?

FlipStone over 8 years ago

Just to add to this myself, I did some tests and I think the non-layout option is both faster and more memory-efficient.

I calculated the time needed to do an onUpdate in my watchface and the 'calculated' UI was 30-50% faster as well as using 25-40% less memory. The layout.xml way is nice to fine tune but other than that using dynamic calculations seems to be the preferred way for me.

Former Member over 8 years ago

The compiler generated code that is produced by layouts may be slightly less efficient than what you could do manually, but I wouldn't expect a major difference there. There aren't any tools to profile at the level you are describing. You can pass '-g' to the compiler to get the assembly output, which could allow you to compare how different code blocks compile. From a code execution standpoint, less instructions is generally going to be faster.

You could use some of the 1Hz watchface profiling tools to see what the simulator estimates execution time of bits of code are. This option would allow you to profile the time required for your graphical operations, which wouldn't be represented as well at an opcode level.

FlipStone over 8 years ago

THanks for commenting on this Brian...

I made my calculations using the System.getTimer method (not optimal of course but lacking a better way). But also after uploading a version using the 'calculated' layout I got reports of it being fast again (as opposed to the one using the layout.xml... which was slow apparently).

Interesting to know about the -g option and will also look into the 1hz profiling options... thanks!