Printable View
Hi all!
Since the switch statement doesn't work for Strings well i had to use a lot of if and else statements + equals().
I heard that lot of if-else statements make the code less efficient. I have to improve the efficiency of my code and was wondering how to replace (and with what) all those if-else statements to make my code more efficient.
Are you sure the inefficiency is caused by the if-else statements?Quote:
Originally Posted by Tsubasa
An efficient implementation of a switch statement involves the use of a "jump table". This can be emulated by the use of a HashMap. You store the Strings as keys and associated with each key is an object of a class (called Case for example) sporting a perform method.
A "switch" would then go like this: Use the selection String to get the corresponding Case object from the HashMap and call its perform method.
Note. In the next version of Java, Strings are likely to be allowed in switch statements.
Where did you hear that? Switch statements are logically a restricted form of if...else constructs, so both will be compiled to basically the same p-code. So, for the same data, they will perform the same. If..elses are one of the basics of coding - the 'Selection' in Sequence, Selection & Iteration.Quote:
Originally Posted by Tsubasa
How do you know you have to improve the efficieny? What you are considering is an optimization. The cardinal rule with optimization is "Don't Do It". The next rule is "Don't Do It Unless You Have To". This means you should have evidence that there is some performance problem before considering it. The third rule is "Do It Properly". This means profiling the code to find out exactly which bits are running too slow.Quote:
I have to improve the efficiency of my code and was wondering how to replace (and with what) all those if-else statements to make my code more efficient.
Focusing on well designed and written code will give far more performance benefits than looking at language constructs.
More bugs have been introduced into programs through premature optimization than any other cause, including pure stupidity...
W.Wulf
Just to add to the valid points made by dlorde. Even an experienced programmer will often find that the code that a profiler shows is hogging resources isn't the code that you thought was the prime candidate for optimisation. And without a profiler it's often difficult to tell whether your code tweaks are making things better or worse. So, basically, your probably wasting your time unless you have access to a profilerQuote:
The third rule is "Do It Properly". This means profiling the code to find out exactly which bits are running too slow.
A final point is if you really do need to optimise your code is it the actual performance or the perceived performance you need to improve. For example, if the user has to wait several seconds every time they save a file then running the save on a background thread can mean that even though the save actually takes longer the user feels the performance has improved because the user interface doesn't lock waiting for the save to complete .
If you have a colossal horde of if - elses, that is a point for redesign. While if - elses as such do not produce any performance issue, when going over the top with it produces quite unreadable code. If else structures always handle variable relations, and when those are changed by sudden turbulence in design / requirements, complicated nested if -elses can be pain to work out.
So, kinda to contrast your initial point. Method calls can be expensive, and they are more expensive an approach than a huge block of if-elses, but it tends to be wisdom to prefer readability and design rather than hunt small performance gains. Keep methods tiny, have more of them if need be. Try to break if-elses to smaller, understandable bits, that handle "currently pressing point only." That way, when optimizing with profilers, you have a highly heightened chance of getting to the actual cause of possible performance / resource issues.
This is wrong. Compilers will preferrably use a "jump-table" in the implementation of a switch-statement. This means the selection is very likely to be O(1) instead of the O(N) you'll get if using a corresponding if-else structure (if the selections have equal probability).Quote:
Originally Posted by dlorde
This is bad advice. Code should be "optimized" continously in the sense that the most efficient readily available alternative should be preferred. So if you can use a switch - do it - because it's more expressive, it's more restrictive, and it's likely to be faster than the if-else equivalent. Don't lay down unnecessarily inefficient code.Quote:
What you are considering is an optimization. The cardinal rule with optimization is "Don't Do It". The next rule is "Don't Do It Unless You Have To". This means you should have evidence that there is some performance problem before considering it. The third rule is "Do It Properly". This means profiling the code to find out exactly which bits are running too slow.
In this case the OP couldn't use a switch. Still, thinking in terms of a switch will lead to a much more object oriented solution than the corresponding if-else, as I explained in my previous post. "Optimizing" the code often even leads to better designs.
And focusing on the question asked avoiding pompous handwaving will lead to better advice.Quote:
Focusing on well designed and written code will give far more performance benefits than looking at language constructs.
OK, it may not be entirely accurate, but in Java 5, using the hotspot compiler, 10 million iterations of an if..else and a switch that each have 8 comparisons of a random integer against an integer literal, and perform a simple integer addition in each selected branch, execute 1282 ms and 1218 ms respectively. For 100 million iterations of each, the figures are 12344 ms and 12187 ms respectively. Given the other influences on execution speed, I would suggest that the difference is not significant enough to affect selection of one construct over the other.Quote:
Originally Posted by _uj
It's the advice given by many of the best developers out there. It refers to time comsuming attempts to improve performance when there is no evidence of a performance problem.Quote:
This is bad advice.
This is common sense, and is not what was meant. Where appropriate, use the best performing construct (e.g. StringBuilder not String in loop concatenations) - but most of the time, and especially with basic language constructs, readability and maintainability are overriding.Quote:
Code should be "optimized" continously in the sense that the most efficient readily available alternative should be preferred.
Use it if it's appropriate. It isn't always appropriate. In general, a good OO design should minimize the use of switch statements and multiple if..elses through polymorphism.Quote:
So if you can use a switch - do it - because it's more expressive, it's more restrictive, and it's likely to be faster than the if-else equivalent.
Indeed.Quote:
Don't lay down unnecessarily inefficient code.
OO solutions generally aim to minimize use of switch - some purists say it should never be used.Quote:
Still, thinking in terms of a switch will lead to a much more object oriented solution than the corresponding if-else, as I explained in my previous post.
That sounds more like refactoring - they do overlap, but ISTM the kind of optimization you are describing is generally regarded as refactoring - re-arranging code to be clearer, simpler, better designed.Quote:
"Optimizing" the code often even leads to better designs.
No doubt about it. Pompous handwaving is definitely unproductive ;-)Quote:
And focusing on the question asked avoiding pompous handwaving will lead to better advice.
Premature optimization is the root of all evil in programming...
C.A.R. Hoare
Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
M.A. Jackson
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil...
D. Knuth
There is a famous rule in performance optimization called the 90/10 rule: 90% of a program's execution time is spent in only 10% of its code. The standard inference from this rule is that programmers should find that 10% of the code and optimize it, because that's the only code where improvements make a difference in the overall system performance. But a second inference is just as important: programmers can deoptimize the other 90% of the code (in order to make it easier to use, maintain, etc.), because deterioration (of performance) of that code won't make much of a difference in the overall system performance...
R. Pattis