Is microoptimization worth it in mobile devices?

Question

Usually microoptimization is considered not worth it with the following explanation: it might speed up the program by less that one percent, but noone cares of that minor boost - that's just too little of a change to be noticed.

Furthermore, there might be some event handler that fires one thousand times per second and exits very fast - before it is fired again. Noone cares how fast it is - making it faster can't be noted, because it already "as fast as can be observed".

However in mobile devices energy consumption is an important factor. The same event handler optimized to run ten percent faster will lead to less energy consumed and that's longer battery life and a longer operating device.

How accurate is the latter judgement about mobile devices? Are there any real life examples that confirm or disprove it?

Answer 1

It worth it if measurements say it worth it. For mobile device as well as supercomputers.

EDIT: Little off topic, but about your exemple. If the event is triggerered too many times, then you have a conception problem, and solving that conception problem is the real deal. Not make it less visible by microoptimizing.

You can perform a test in the callback for exemple, to discard too frequents calls, or rework the way callback is called.

In general, it is bad practice to attach callback to « continuous events ». By that I mean events that doesn't trigger once and then done, but that trigger on action that last over time.

Scrolling a page or a slider, for exemple, are continuous events.

You never know how many times thoses events will be triggered. If they are triggered fast enough, your application become lagguy, and if they are triggered too many times, you'll end up with huge CPU load for nothing, potentially making your application lagguy too.

Answer 2

How accurate is the latter judgement about mobile devices?

It's only as accurate as the actual measurements on the actual device that actually indicate that actual optimization will actually help.

Assumptions and judgements are worthless.

Measurements have value.

All optimization (including "microoptimization", whatever that is) is a waste of time until there is an actual measurement that indicates an actual problem where the code actually fails to meet some requirement (for speed, memory, power, or network latency or whatever).

Answer 3

(Assuming speed is your main issue.) Everyone is right.
Except - measurement won't tell you what to optimize.

Measurement will tell you that you need to optimize.
Measurement will tell you how much you saved when you did optimize.

Measurement will not tell you what to optimize.
This technique will tell you what to optimize.

Answer 4

i'm familiar with optimization. i see other people's programs with a different set of eyes -- here's my take:

Usually microoptimization is considered not worth it with the following explanation: it might speed up the program by less that one percent, but noone cares of that minor boost - that's just too little of a change to be noticed.

the funny thing is, one such change leads to 99%. ten such changes make the program noticably faster. for many engineers, changes to their approach of writing a program can make a program execute several times faster. simply being aware of efficiency and writing that way can make your program several times faster without much additional work. such gains are not micro-optimizations, imo.

note: i am never suggesting contextually corner-cutting optimizations in this discussion.

Furthermore, there might be some event handler that fires one thousand times per second and exits very fast - before it is fired again. Noone cares how fast it is - making it faster can't be noted, because it already "as fast as can be observed".

and it's likely already doing more work than necessary since 1kHz is far higher than many cases require. what is this event handler's source, and what are its effects? if it is simply updating the UI and events may be collected and coalesced, then 1kHz dispatch is certainly overkill (far more than 1% - more like 25x). for a system which has mulitple sources and is transmitted in serial, then 1kHz may not be fast enough (e.g. MIDI).

However in mobile devices energy consumption is an important factor. The same event handler optimized to run ten percent faster will lead to less energy consumed and that's longer battery life and a longer operating device. How accurate is the latter judgement about mobile devices? Are there any real life examples that confirm or disprove it?

based on the programs i have seen, there are not very many people considering (or concerned with) such optimizations, even though changing your approach to writing programs can yield incredible gains (>10x or much faster). many that i have seen (in the app development side) just write then take a top down or "hail mary" approach when (/if) performance issues catch up with them. similarly, many will not even take the time to profile until such an occurence. by then, the noise of so many compound inefficencies makes it very difficult to get useful information from a profiler. examples of the hail mary approach would be optimizing the wrong areas (with or without looking for problem areas), or just throwing more cores at problem areas; this happens rather than fixing existing inefficiencies.

for the typical existing program (among the mobile programs i have seen), optimization was not a high concern when it is written. so "yes" they are (in the typical case) worth the time, provided it is in the budget and a priority. in that case, those ten changes which make the program noticably faster can likely be performed in a few hours, and less than a day.

"write lazily and profile in retrospect" as the only action to improve a program is a terrible idea: taking the time to learn how to write an efficient program (as it is written, not by taping it together at the end) is the superior approach (imo); use the right algorithms, forbid wasteful copying, allocations, calculations (+many, many other categories). of course, analyzing performance in retrospect has its merits, but if you write the program to be efficient from the outset you will have a whole new level of efficiency because you learn a lot and consider and evaluate execution from multiple perspectives.

the other thing is that programs should (often) be written for reuse, a poorly written program will introduce changes which may break clients' programs when the inefficiencies are removed (or just remain inefficient to avoid breaking existing programs).

one great benefit of considering it when you write is that you have a very clear idea of how the program will operate (although not a complete picture), you can use this information to aid in the design of the interfaces and how it stores its data. the truth is, an engineer can implement something which is several (e.g. >10x) times faster than the standard "one size fits all" solutions provided with the OS.

finally, it's also worth it beyond mobile devices. there are lot of inefficient programs out there, written with the mindset that hardware will be faster in two years (frequent rationale, even for programs written today!). while that's not incorrect, it's over-optimistic. as well, parallelization has purpose but it is the wrong "default solution" for many programs. many of these existing programs can be best improved by first removing the existing inefficiencies.

so... there are typically a ton of those 1%, 2%, 7% (and much worse) cases in the real world. correcting them or (more importantly) not writing/exposing them in the first place can provide great benefits. many of those cases can be easily located and corrected (provided the engineer has some experience with this). it can, however, really be a pain to correct and re-test after the fact. if a program is to optimal, it will ideally be written that way from the outset.

as an end user, it's irritating to continuously wait for slow programs and to throw twice the hardware at problems created by slow/inefficient programs: Q: "what are you going to do now that you have twice the cores and twice the memory?" A: "regain the responsiveness and productivity i had before i upgraded my software -- that's about it". quite inconsiderate of the developer (imho).