Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
2  
IMHO, as with optimization in general, you can only get a reliable answer via measurements. But the question is good nevertheless, +1 :-) –  Péter Török Sep 20 '11 at 7:27
    
Define your terms. I get the impression that you're talking about runtime micro-optimisation, and you specifically mention energy usage, but in the context of small devices those aren't the only things which might be worth optimising. Executable size and memory footprint are others. –  Peter Taylor Sep 20 '11 at 13:29
add comment

4 Answers 4

up vote 12 down vote accepted

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.

share|improve this answer
    
Okay, what do I measure - Power consumption or anything else? –  sharptooth Sep 20 '11 at 7:30
3  
Measure what matter for your user. If consumption is a problem (and it is on mobile device) then measure it, and act according to measurements. –  deadalnix Sep 20 '11 at 7:36
    
What about commercial considerations - is it profitable to do the optimization? A bigger battery might be cheaper than the engineering time for low-mid volume products. A slower user interface with 5% less battery life is better than no product in the market place. It's easy to burn $$$ never achieving perfection. –  mattnz Sep 21 '11 at 5:19
add comment

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).

share|improve this answer
add comment

(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.

share|improve this answer
2  
Isn't profiling better than this random sampling technique? –  S.Lott Sep 20 '11 at 15:40
1  
@S.Lott q: is viewing the mural from two blocks away better than viewing it from two feet away? a: you really don't see the mural when viewed from a single perspective. both are important. sampling/profiling can be a huge waste of time if that's the only perspective you ever take to evaluate your program's performance. –  justin Sep 21 '11 at 0:11
    
@Justin: "sampling/profiling can be a huge waste of time if..."? What? You provided a link on sampling, as if profiling wasn't as good as sampling. Now you're saying both are potentially bad? What's the third choice, different from the sampling in the link and profiling (which seems more complete and useful to me)? If there's a third choice, could you update your answer to explain how all these choices fit together? I'm still unclear on what's wrong with profiling. The link doesn't explain why sampling is better. –  S.Lott Sep 21 '11 at 3:40
    
@S.Lott: Well I know it's a minority view, but a number of people have tried it and agree. If I can make an analogy, archeologists use hand tools and brushes, because the fine details are important, and they need to understand them. The only profiler I know of that gets close is Zoom. And if you try it you'll see it's still quite different, because it concentrates on understanding. It's the method used here. –  Mike Dunlavey Sep 21 '11 at 3:47
    
@Mike Dunlavey: "have tried it and agree"? What is it? Sampling? Profiling? Or whatever the third choice is when "sampling/profiling can be a huge waste of time if..."? Are you saying profiling works? Or profiling requires special tools? –  S.Lott Sep 21 '11 at 3:59
show 10 more comments

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).

share|improve this answer
1  
Taking time to get it perfect is a nice luxury for some. One company I knew of micro-optimised their way out of business. Their competitors product was inferior in every way, slower and needed recharging more often da da da, but it was possible for a user to buy one at a price the user was prepared to pay..... –  mattnz Sep 21 '11 at 5:17
    
@mattnz a fair example (+1). for the record, i'm not making the case for a perfect program. my post emphasized good design with higher emphahsis and consideration for performance than is typical. in defense of costs: you can often strike a good balance between a well written program which performs well with components which can be reused easily versus a poor/inefficient design that ends up having a relatively short lifetime. one must account for maintenance costs and recognize each design's strengths and weaknesses. (cont) –  justin Sep 21 '11 at 5:56
    
(cont) good implementations tend to be reusable and have long lives while poorly written programs face obsolescence sooner and often require high maintentance costs (e.g. debugging, tuning, rewriting, re-testing before and after shipment). poorly written programs are frequently a greater waste of development time/resources in the long run. –  justin Sep 21 '11 at 5:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.