How cheap are objects?

Former Member over 7 years ago

Hey, It's me again, now with a question about the nature of the language and performance.

Being this a fully OOP language the only way to organize the code is on modules, methods and objects. I feel the temptation now that my project is growing of creating some classes to separate concerns and make the code more readable, intuitive and maintainable.

So before I throw myself into the madness of OOP design, I want to know how cheap are objects to create and to keep in memory versus calling functions that takes all their arguments.

Let my give you an example: I have a function that renders bi-color text on screen. I pass this function all the arguments it needs (which are like 8?) and the code of such function is directly on the watchface object. To me it makes sense to create a class that handles this and to instantiate it, for example, during onLayout.

For objects that I instantiate on certain life-cycle methods and then I re-use them I think it is worth it, but what about (for example) creating objects on loops? Is that an acceptable practice?

What about custom Drawables that are used on layout.xml? It will make my layout.xml easier to write and the code related to it also, but, what about performance of such practices? I can't find anything on the programmers guide about this.

Thanks and regards.

jim_m_58 over 7 years ago

lots of things come into play here like scoping, and simple objects vs complex ones.

Former Member over 7 years ago in reply to jim_m_58

Let's focus on a concrete example then. The double-color text that I said before.

Currently it is a function that it is invoked on every update. It requires several scoped properties to be accessed. It is called like this:

renderBiColorText(dc,startStr,text,Graphics.COLOR_WHITE,Graphics.COLOR_PINK,circleScreen.getZeroAtHeight(Y+textHeight),Y,font);

And this is the code

hidden function renderBiColorText(dc,textA,textB,colorA,colorB,X,Y,font) {
        var textAWidth = dc.getTextWidthInPixels(textA,font);
        dc.setColor(colorA, Graphics.COLOR_TRANSPARENT);
        dc.drawText(X,Y,font,textA,Graphics.TEXT_JUSTIFY_LEFT);
        dc.setColor(colorB, Graphics.COLOR_TRANSPARENT);
        dc.drawText(X + textAWidth,Y,font,textB,Graphics.TEXT_JUSTIFY_LEFT);
}

I like how explicit everything is, but it just adds to my main watchface code.

I can see a simple object taking colors, coordinates font and text on initialization and then just a draw method. Then this could be instantiated onLayout for example. Also I could add a couple of methods to update the texts, so I don't need to re-create the object on every on-update.

Then such object could even be expanded to become a custom drawable that I can use on layout.xml

Would several like this be good? How does the things you said apply here?

jim_m_58 over 7 years ago in reply to Former Member

I think you're looking for a simple answer to a complex question, but just with this same, there are variables involved. It's not just runtime memory, but also code size and speed.

Any time you use a function vs in-line there's a tiny speed hit, as the stack frame needs to be built, etc. But inlining things can increase the code size.

And in the function, you're calling setColor twice, where it would be more efficent to set colorA, do everything that's that color, then set colorB and do the same for efficency.

In other words, there are trade offs. for example, in onPartialUpdate, you probably want to code for execution speed over memory efficiency as there, literally, every ms counts.

And in the same way, if you're tight on memory, you may want to code things differently. A prime example here is older devices with a max of 16k for a data field, and a common approach there is to use dc calls vs layouts.

"view memory" in the sim will help you tune your code.