Optimization Guidelines

Definitely one thing I can recommend:

Do not repeat certain computations like
width / 2

Rather do this:

var center = width / 2;

Definitely one thing I can recommend:

Do not repeat certain computations like
width / 2

Rather do this:

var center = width / 2;

Thank you for the tip, but that didn't help much: still running good in emulator but stuttering on the watch.
So if there are no profile tools (and I didn't find any clarification on that topic in either programmers guide or developer documentation), then I'll try to do this plain old way: sequentially remove blocks of code and check how does this affect device performance.

Considering how current FR230 firmware treats manually installed data fields, this can be painful process: sometimes when I try to set up field, which I loaded directly to watch, data screen setup shows 3 to 5 of 2 fields used despite no other IQ data fields being used or downloaded to device.

But still, if someone knows the performance tricks, please, share.
Thanks in advance.

If it could help speed up things for you, try removing this code first and check the performance.

I know drawing arcs is a costly operation. And then you do it in a for loop to begin with...

for (var radius = width / 2 - 28; radius <= (width / 2 - stepWidth * (4 - mGpsAccuracy)); radius += stepWidth) {
dc.drawArc(width / 2, dc.getHeight() / 2, radius, Gfx.ARC_CLOCKWISE, 56, 28);
}


If it could help speed up things for you, try removing this code first and check the performance.

I know drawing arcs is a costly operation. And then you do it in a for loop to begin with...

for (var radius = width / 2 - 28; radius <= (width / 2 - stepWidth * (4 - mGpsAccuracy)); radius += stepWidth) {
dc.drawArc(width / 2, dc.getHeight() / 2, radius, Gfx.ARC_CLOCKWISE, 56, 28);
}


Thanks for the info, will certainly try that.
But as you could guess reading this code, I wanted to impement gps indicator, which consists of several coned arc segments where amount of segments depends on gps accuracy. Maybe if this part is marked as culprit during on-device tests, I'll try to let it slide with a single fillRectangle. Especially considering that during normal activity this doesn't change often and if the operation is CPU intensive, this will also eat battery.

Too bad we can't prerender immutable parts as a bitmap and use it to draw with a single operation during onUpdate 8((

Couple of things you could do to display an arc, without actually drawing one for something like the GPS accuracy where there are 5 specific levels:

1) use a bitmap for each of the levels

2) a custom font where you map characters to a image in that font - for GPS you could use "0" to "4", for example, and then just do a toString() on the value you get and then you have the image for that character displayed by just using that font. With a custom font, you can also easily change the color, without having different bitmaps. Many things where you see icons for different things (like bluetooth status) use a custom "icon font", for example.

dc.drawText(x,y,arcfont,"4",Gfx.TEXT_JUSTIFY_CENTER);

would draw the arc for "QUALITY_GOOD" for instance.

If you want to know which portions of your code are taking a long time to execute on hardware, I recommend timing your code. You can use Toybox.System.getTimer() to read the free-running millisecond timer on the device. By reading this timer at various points in your code, you can compute the execution time of each section. The call to the timer shouldn't have much of an impact on the timing, but printing out any results will, so make sure you collect all your timings before doing any println() calls.

Once you know which sections are slow, you can focus on figuring out ways to speed them up.

I'm going to capture some of these thoughts and add them to the FAQ.

Thanks everyone, below are the results of my little research.
Replacing the arcs with filled squares helped a little, but still timer was twitching at times during several minutes observation period. Thus I decided to also create pace and distance display values only when the visible values has changed, this helped another little bit. Most visible impact though I've found when changed battery read interval from second to minute. Don't know that's just a coincidence or System.getSystemStats() really takes noticeable time to execute.
Right now data field is working rather smooth and I'll take some time to field-test it during actual running for a couple of weeks to find out most obvious bugs.
Meanwhile, since the performance topic became my obsession recently, I'll continue to run simulator tests with a method offered by Brian.ConnectIQ, but since there is no inbuilt performance tool it'll take some time to analyse.

Also I'd like to give personal thanks jim_m_58 for the tip on how to implement symbols: I've already seen this technique discussed on forum, but wasn't sure that this is the common practice. Also didn't know that color could be changed without using another set of images, it's nice that bitmap tinting is present in some way, gives a lot of ways for personalization. Still, there's another bottleneck: while data field has only 16kb available memory, using bitmap font with alpha channel may dramatically increase memory footprint.

optimisaion is both a hit and miss and plenty of coffee and tries.
Getting memory usage down is a BIG BIG thing and every little bit helps.
Things like shortening variable names (eg PACE vs p)

for the screen updates, FPS if I remember is like 1sec and you need the updates etc to finish in approx 500ms for no twitching to occur.
Littering plenty of println and systimers helps.

also helps is to actually put these little systimers on the display itself to determine where is eating up stuffs.
Complex DataFields like mine takes a LOT of optimisation.

Good Luck.