Which piece of code has better performance?
Pseudocode:
1)
prvate String doSth(String s) {
...
return s.substring(0, Math.min(s.length(), constparam));
}
2)
prvate String doSth(String s) {
if (s.length() > constparam) {
return s.substring(0, constparam);
}
return s;
}
In most cases (99%) - s.length < constparam.
This method is invoked 20-200 times per second.
Which solution (and why) would have a better performance?
Will it be a significant impact?
Let's look at what each one does:
1 always finds the lower of two values and always calls substring returning a new String.
2 always compares two values and sometimes calls sub string so sometimes creates a new String.
So 2, because some of the time it will do less work and create less objects.
If s.length < constparam for most of the cases, case 2 will be faster as substring() operation need not to be done for most of the cases.
public static int min(int a, int b) {
return (a <= b) ? a : b;
}
From Math. I would run a JMH test, and I would say that the two presented solution won't show statistically significant differences.
If you are really concerned about performance, don't even use substring (check the code, it has 3 ifs and creates a new String every time you call it), but you should operate with char arrays.
And then again: in real life I don't think it will matter. Run the JMH test with some real parameters (lengths of strings and constant values). I think you'll see numbers which are enough for almost every sane use-case.
Function substring with arguments (0, length) returns the string unmodified.
The difference is checking if s.length() > constparam, but basically it's what Math.min does.
So im my opinion, there's almost no performance differences, assuming substring invocation takes much more time than this conditional or Math.min, or even without this assumption.
The branching may cost something like a few nanoseconds. In both cases there's no needless char[] copying. The method call overhead is rather big, but gets optimized out.
A few nanoseconds times 200 make a few microseconds at most. The difference between the two approaches is smaller, so you may spend 0.0001% the time on this. This is a very rough estimate, but even if I was off by a factor of thousand, there's no point in optimizing here.
Fairly easy, if the BigInteger number is 543 I want it to cut off the last digit so that it is 54.
Two easy ways to do this can be :
Use strings, get substring and create new biginteger with the new value.
Use BigIntegers divide method with number 10. ( 543 / 10 = 54.3 => 54 )
The thing is I will be performing this a lot of times with large integers of course.
My guess is that playing around with strings will be slower but then again I haven't used Bigintegers so much and have no idea how expensive the "divide" operation is.
The speed is essential here, what is the fastest way to implement this (memory is no problem only speed) ?
Others solutions are also welcome.
Divide by 10 is most likely going to be faster.
Dividing by 10 is much faster than using a substring operation. Using the following benchmark, I get about 161x times (ratio is proportional to bit count)
long divTime = 0;
long substrTime = 0;
final int bitsCount = 1000;
for (int i = 0; i < 1000; ++i) {
long t1, t2;
BigInteger random = new BigInteger(bitsCount, new Random());
t1 = System.currentTimeMillis();
random.divide(BigInteger.TEN);
t2 = System.currentTimeMillis();
divTime += (t2 - t1);
t1 = System.currentTimeMillis();
String str = random.toString();
new BigInteger(str.substring(0, str.length() - 1));
t2 = System.currentTimeMillis();
substrTime += (t2 - t1);
}
System.out.println("Divide: " + divTime);
System.out.println("Substr: " + substrTime);
System.out.println("Ratio: " + (substrTime / divTime));
If you create a BigInteger statically that has the number 10, and then use that to divide by 10, that will be potentially the fastest way to do this. It beats creating a temporary new BigInteger every time.
The problem with substring is that you are essentially creating a new String every single time, and that is much slower, not to mention the slowness that is iterating through a string to get its substring.
The fastest way is dividing the number by 10 with an efficient internal division implementation. The internals of that operation are behind the scenes but certainly non-trivial since the number is stored base-2.
The fastest possible implementation would probably be to use a data type whose internal representation uses base 10, i.e. some sort of BCD. Then, division by 10 would simply mean dropping the last byte (or even just incrementing/decrementing an index if you implement it the right way).
Of course, you'd have to implement all arithmetic and other operations you need from scratch, making this a lot of work.
It's probably premature to even be asking this question. Do it the obvious way (divide by ten), then benchmark it, and optimize it if you need to. Converting to a string representation and back will be much slower.
The toString() alone is probably slower than the substring.
Various people have said that dividing by 10 will be faster than converting to a string and taking the substring. To understand why, just think about the computation involved in converting from a BigInteger to a String, and vice versa. For example:
/* simplified pseudo code for converting +ve numbers to strings */
StringBuffer sb = new StringBuffer(...);
while (number != 0) {
digit = number % 10;
sb.append((char)(digit + '0'));
number = number / 10;
}
return sb.toString();
The important thing to note is that converting from a number to a string entails repeatedly dividing by 10. Indeed the number of divisions is proportional to log10(number). Going in the other direction involves log10(number) multiplications. It should be obvious that this is much more computation than a single division by 10.
if performance is crucial... don't use java
In languages which compile to machine code (for instance c or c++) the integer divide is quicker by a huge factor. String operations use (or can use) memory allocations and are therefore slow.
My bet is that in java int divisions will be quicker too. Otherwise their vm implementation is really weird.
All over the web, code samples have for loops which look like this:
for(int i = 0; i < 5; i++)
while I used the following format:
for(int i = 0; i != 5; ++i)
I do this because I believe it to be more efficient, but does this really matter in most cases?
Everybody loves their micro-optimizations, but this would not make a difference as far as I can see. I compiled the two variations with g++ on for Intel processors without any fancy optimizations and the results are for
for(int i = 0; i < 5; i++)
movl $0, -12(%ebp)
jmp L2
L3:
leal -12(%ebp), %eax
incl (%eax)
L2:
cmpl $4, -12(%ebp)
jle L3
for(int i = 0; i != 5; ++i)
movl $0, -12(%ebp)
jmp L7
L8:
leal -12(%ebp), %eax
incl (%eax)
L7:
cmpl $5, -12(%ebp)
jne L8
I think jle and jne should translate to equally fast instructions on most architectures.
So for performance, you should not distinguish between the two. In general, I would agree that the first one is a little safer and I also think more common.
EDIT (2 years later): Since this thread recently got again a lot of attention, I would like to add that it will be difficult to answer this question generally. Which versions of code are more efficient is specifically not defined by the C-Standard [PDF] (and the same applies to C++ and probably also for C# ).
Section 5.1.2.3 Program execution
§1 The semantic descriptions in this International Standard describe the behavior of an abstract machine in which issues of optimization are irrelevant.
But it is reasonable to assume that a modern compiler will produce equally efficient code and I think that in only very rare cases will the loop-test and the counting expression be the bottleneck of a for-loop.
As for taste, I write
for(int i = 0; i < 5; ++i)
If for some reason i jumps to 50 in the loop, your version would loop forever. The i < 5 is a sanity check.
The form
for (int i = 0; i < 5; i++)
is idiomatic, so it's easier to read for experienced C programmers.
Especially when used to iterate over an array.
You should write idiomatic code whenever possible as it reads faster.
It is also a little safer in situations when you modify i inside the loop or use an increment different then 1.
But it's a minor thing.
It's best to carefully design your loop and add some asserts to catch broken assumptions early.
If the increment rule changes slightly you immediately have an infinite loop. I much prefer the first end condition.
It depends on the language.
C++ texts often suggest the second format as that will work with iterators which can be compared (!=) directly but not with a greater to or less than condition. Also pre increment can be faster than post increment as there is no need for a copy of the variable for comparison - however optimisers can deal with this.
For integers either form works. The common idiom for C is the first one whilst for C++ it is the second.
For C# and Java use I would foreach to loop over all things.
In C++ there is also the std::for_each function requiring a use of a functor which for simple cases is probably more complex than either example here and the Boost FOR_EACH which can look like the C# foreach but is complex inside.
With regards to using ++i instead of i++, it doesn't make a difference with most compilers, however ++i could be more efficient than i++ when used as an iterator.
There's actually four permutations on what you give. To your two:
for(int i = 0; i < 5; i++)
for(int i = 0; i != 5; ++i)
We can add:
for(int i = 0; i < 5; ++i)
for(int i = 0; i != 5; i++)
On most modern machines with modern compilers it shouldn't be surprising that these will be of exactly the same efficiency. It could be just about possible that you may one day find yourself programming for some small processor where there's a difference between equality comparisons and less-than comparisons.
It may in some case make more sense to a particular mind with a particular case to think of "less than" or of "not equals" depending on the reason why we chose 0 and 5, but even then what makes one seem obvious to one coder may not with another.
More abstractly, these are of the forms:
for(someType i = start; i < end; i++)
for(someType i = start; i != end; ++i)
for(someType i = start; i < end; ++i)
for(someType i = start; i != end; i++)
An obvious difference here is that in two cases someType must have a meaning for < and for the rest it must have a meaning for !=. Types for which != is defined and < isn't are quite common, including quite a few iterator objects in C++ (and potentially in C# where the same approach as STL iterators is possible and sometimes useful, but neither as idiomatic, directly supported by common libraries nor as often useful since there are rival idioms with more direct support). It's worth noting that the STL approach is specifically designed so as to include pointers within the set of valid iterator types. If you're in the habit of using the STL you'll consider the forms with != far more idiomatic even when applied to integers. Personally a very tiny amount of exposure to it was enough to make it my instinct.
On the other hand, while defining < and not != would be rarer, it's applicable to cases where either we replace the increment with a different increase in i's value, or where i may be altered within the loop.
So, there's definite cases on both sides where one or the other is the only approach.
Now for ++i vs i++. Again with integers and when called directly rather than through a function that returns the result (and chances are even then) the practical result will be exactly the same.
In some C-style languages (those without operator over-loading) integers and pointers are about the only cases there is. We could just about artificially invent a case where the increment is called through a function just to change how it goes, and chances are the compiler will still turn them into the same thing anyway.
C++ and C# allow us to override them. Generally the prefix ++ operates like a function that does:
val = OneMoreThan(val);//whatever OneMoreThan means in the context.
//note that we assigned something back to val here.
return val;
And the postfix ++ operates like a function that does:
SomeType copy = Clone(val);
val = OneMoreThan(val);
return copy;
Neither C++ nor C# match the above perfectly (I quite deliberately made my pseudo-code match neither), but in either case there may be a copy or perhaps two made. This may or may not be expensive. It may or may not be avoidable (in C++ we often can avoid it entirely for the prefix form by returning this and in the postfix by returning void). It may or may not be optimised away to nothing, but it remains that it could be more efficient to do ++i than i++ in certain cases.
More particularly, there's the slight possibility of a slight performance improvement with ++i, and with a large class it could even be considerable, but barring someone overriding in C++ so that the two had completely different meanings (a pretty bad idea) it's not generally possible for this to be the other way around. As such, getting into the habit of favouring prefix over postfix means you might gain an improvement mayone one time in a thousand, but won't lose out, so it's a habit C++ coders often get into.
In summary, there's absolutely no difference in the two cases given in your question, but there can be in variants of the same.
I switched to using != some 20+ years ago after reading Dijkstra's book called "A Discipline of Programming". In his book Dijkstra observed that weaker continuation conditions lead to stronger post-conditions in loop constructs.
For example, if we modify your construct to expose i after the loop, the post-condition of the fist loop would be i >= 5, while the post-condition of the second loop is a much stronger i == 5. This is better for reasoning about the program in formal terms of loop invariants, post-conditions, and weakest pre-conditions.
I agree with what's been said about readability - it's important to have code that's easy for a maintainer to read, although you'd hope that whoever that is would understand both pre- and post-increments.
That said, I thought that I'd run a simple test, and get some solid data about which of the four loops runs fastest.
I'm on an average spec computer, compiling with javac 1.7.0.
My program makes a for loop, iterating 2,000,000 time over nothing (so as not to swamp the interesting data with how long it takes to do whatever is in the for loop). It use all four types proposed above, and times the results, repeating 1000 times to get an average.
The actual code is:
public class EfficiencyTest
{
public static int iterations = 1000;
public static long postIncLessThan() {
long startTime = 0;
long endTime = 0;
startTime = System.nanoTime();
for (int i=0; i < 2000000; i++) {}
endTime = System.nanoTime();
return endTime - startTime;
}
public static long postIncNotEqual() {
long startTime = 0;
long endTime = 0;
startTime = System.nanoTime();
for (int i=0; i != 2000000; i++) {}
endTime = System.nanoTime();
return endTime - startTime;
}
public static long preIncLessThan() {
long startTime = 0;
long endTime = 0;
startTime = System.nanoTime();
for (int i=0; i < 2000000; ++i) {}
endTime = System.nanoTime();
return endTime - startTime;
}
public static long preIncNotEqual() {
long startTime = 0;
long endTime = 0;
startTime = System.nanoTime();
for (int i=0; i != 2000000; ++i) {}
endTime = System.nanoTime();
return endTime - startTime;
}
public static void analyseResults(long[] data) {
long max = 0;
long min = Long.MAX_VALUE;
long total = 0;
for (int i=0; i<iterations; i++) {
max = (max > data[i]) ? max : data[i];
min = (data[i] > min) ? min : data[i];
total += data[i];
}
long average = total/iterations;
System.out.print("max: " + (max) + "ns, min: " + (min) + "ns");
System.out.println("\tAverage: " + (average) + "ns");
}
public static void main(String[] args) {
long[] postIncLessThanResults = new long [iterations];
long[] postIncNotEqualResults = new long [iterations];
long[] preIncLessThanResults = new long [iterations];
long[] preIncNotEqualResults = new long [iterations];
for (int i=0; i<iterations; i++) {
postIncLessThanResults[i] = postIncLessThan();
postIncNotEqualResults[i] = postIncNotEqual();
preIncLessThanResults[i] = preIncLessThan();
preIncNotEqualResults[i] = preIncNotEqual();
}
System.out.println("Post increment, less than test");
analyseResults(postIncLessThanResults);
System.out.println("Post increment, inequality test");
analyseResults(postIncNotEqualResults);
System.out.println("Pre increment, less than test");
analyseResults(preIncLessThanResults);
System.out.println("Pre increment, inequality test");
analyseResults(preIncNotEqualResults);
}
}
Sorry if I've copied that in wrong!
The results supprised me - testing i < maxValue took about 1.39ms per loop, whether using pre- or post-increments, but i != maxValue took 1.05ms. That's a that's either a 24.5% saving or a 32.5% loss of time, depending on how you look at it.
Granted, how long it takes a for loop to run probably isn't your bottleneck, but this is the kind of optimisation that it's useful to know about, for the rare occasion when you need it.
I think I'll still stick to testing for less than, though!
Edit
I've tested decrementing i as well, and found that this doesn't really have an effect on th time it takes - for (int i = 2000000; i != 0; i--) and for (int i = 0; i != 2000000; i++) both take the same length of time, as do for (int i = 2000000; i > 0; i--) and for (int i = 0; i < 2000000; i++).
In generic code you should prefer the version with != operator since it only requires your i to be equally-comparable, while the < version requires it to be relationally-comparable. The latter is a stronger requirement than the former. You should generally prefer to avoid stronger requrements when a weaker requirement is perfectly sufficient.
Having said that, in your specific case if int i both will work equally well and there won't be any difference in performance.
I would never do this:
for(int i = 0; i != 5; ++i)
i != 5 leaves it open for the possibility that i will never be 5. It's too easy to skip over it and run into either an infinite loop or an array accessor error.
++i
Although a lot of people know that you can put ++ in front, there are a lot of people who don't. Code needs to be readable to people, and although it could be a micro optimization to make the code go faster, it really isn't worth the extra headache when someone has to modify the code and figure why it was done.
I think Douglas Crockford has the best suggestion and that is to not use ++ or -- at all. It can just become too confusing (may be not in a loop but definitely other places) at times and it is just as easy to write i = i + 1. He thinks it's just a bad habit to get out of, and I kind of agree after seeing some atrocious "optimized" code.
I think what crockford is getting at is with those operators you can get people writing things like:
var x = 0;
var y = x++;
y = ++x * (Math.pow(++y, 2) * 3) * ++x;
alert(x * y);
//the answer is 54 btw.
It is not a good idea to care about efficiency in those cases, because your compiler is usually smart enough to optimize your code when it is able to.
I have worked to a company that produces software for safety-critical systems, and one of the rules was that the loop should end with a "<" instead of a !=. There are several good reasons for that:
Your control variable might jump to a higher value by some hw problem or some memory invasion;
In the maintenance, one could increment your iterator value inside the loop, or do something like "i += 2", and this would make your loop to roll forever;
If for some reason your iterator type changes from "int" to "float" (I don't know why someone would do that, but anyways...) an exact comparison for float points is a bad practice.
(The MISRA C++ Coding Standard (for safety-critical systems) also tell you to prefer the "<" instead of "!=" in the rule 6-5-2. I don't know if I can post the rule definition here because MISRA is a paid document.)
About the ++i or i++, I'd preffer to use ++i. There is no difference for that when you are working with basic types, but when you are using a STL iterator, the preincrement is more efficient. So I always use preincrement to get used to it.
I have decided to list the most informative answers as this question is getting a little crowded.
DenverCoder8's bench marking clearly deserves some recognition as well as the compiled versions of the loops by Lucas. Tim Gee has shown the differences between pre & post increment while User377178 has highlighted some of the pros and cons of < and !=. Tenacious Techhunter has written about loop optimizations in general and is worth a mention.
There you have my top 5 answers.
DenverCoder8
Lucas
Tim Gee
User377178
Tenacious Techhunter
For the record the cobol equivalent of the "for" loop is:-
PERFORM VARYING VAR1
FROM +1 BY +1
UNTIL VAR1 > +100
* SOME VERBOSE COBOL STATEMENTS HERE
END-PERFORM.
or
PERFORM ANOTHER-PARAGRAPH
VARYING VAR2 BY +1
UNTIL TERMINATING-CONDITION
WITH TEST AFTER.
There are many variations on this. The major gotcha for peoples whose minds have not been damaged by long exposure to COBOL is the, by default, UNTIL actually means WHILE i.e. the test is performed at the top of the loop, before the loop variable is incremented and before the body of the loop is processed. You need the "WITH TEST AFTER" to make it a proper UNTIL.
The second is less readable, I think (if only because the "standard" practice seems to be the former).
Numeric literals sprinkled in your code? For shame...
Getting back on track, Donald Knuth once said
We should forget about small
efficiencies, say about 97% of the
time: premature optimization is the
root of all evil.
So, it really boils down to which is easier to parse
So... taking into account both of the above, which of the following is easier for a programmer to parse?
for (int i = 0; i < myArray.Length; ++i)
for (int i = 0; i != myArray.Length; ++i)
Edit: I'm aware that arrays in C# implement the System.Collections.IList interface, but that's not necessarily true in other languages.
Regarding readability. Being a C# programmer who likes Ruby, I recently wrote an extension method for int which allows the following syntax (as in Ruby):
4.Times(x => MyAction(x));
To sum up pros and cons of both options
Pros of !=
when int is replaced with some iterator or a type passed via template argument there is better chance it will work, it will do what is expected and it will be more efficient.
will 'loop forever' if something unpredicted happens to the i variable allowing bug detection
Pros of <
as other say is as efficient as the other one with simple types
it will not run 'forever' if i is increased in the loop or 5 is replaced with some expression that gets modified while the loop is running
will work with float type
more readable - matter of getting used to
My conclusions:
Perhaps the != version should be used in majority of cases, when i is discrete and it is as well as the other side of the comparison is not intended to be tampered within the loop.
While the presence of < would be a clear sign that the i is of simple type (or evaluates to simple type) and the condition is not straightforward: i or condition is additionally modified within the loop and/or parallel processing.
It appears no one has stated the reason why historically the preincrement operator, ++i, has been preferred over the postfix i++, for small loops.
Consider a typical implementation of the prefix (increment and fetch) and the postfix (fetch and increment):
// prefix form: increment and fetch
UPInt& UPInt::operator++()
{
*this += 1; // increment
return *this; // fetch
}
// posfix form: fetch and increment
const UPInt UPInt::operator++(int)
{
const UPInt oldValue = *this;
++(*this);
return oldValue;
}
Note that the prefix operation can be done in-place, where as the postfix requires another variable to keep track of the old value. If you are not sure why this is so, consider the following:
int a = 0;
int b = a++; // b = 0, the old value, a = 1
In a small loop, this extra allocation required by the postfix could theoretically make it slower and so the old school logic is the prefix is more efficient. As such, many C/C++ programmers have stuck with the habit of using the prefix form.
However, noted elsewhere is the fact that modern compilers are smart. They notice that when using the postfix form in a for loop, the return value of the postfix is not needed. As such, it's not necessary to keep track of the old value and it can be optimized out - leaving the same machine code you would get from using the prefix form.
Well... that's fine as long as you don't modify i inside your for loop. The real "BEST" syntax for this entirely depends on your desired result.
If your index were not an int, but instead (say) a C++ class, then it would be possible for the second example to be more efficient.
However, as written, your belief that the second form is more efficient is simply incorrect. Any decent compiler will have excellent codegen idioms for a simple for loop, and will produce high-quality code for either example. More to the point:
In a for loop that's doing heavy performance-critical computation, the index arithmetic will be a nearly negligible portion of the overall load.
If your for loop is performance-critical and not doing heavy computation such that the index arithmetic actually matters, you should almost certainly be restructuring your code to do more work in each pass of the loop.
When I first started programming in C, I used the ++i form in for loops simply because the C compiler I was using at the time did not do much optimization and would generate slightly more efficient code in that case.
Now I use the ++i form because it reads as "increment i", whereas i++ reads as "i is incremented" and any English teacher will tell you to avoid the passive voice.
The bottom line is do whatever seems more readable to you.
I think in the end it boils down to personal preference.
I like the idea of
for(int i = 0; i < 5; i++)
over
for(int i = 0; i != 5; ++i)
due to there being a chance of the value of i jumping past 5 for some reason. I know most times the chances on that happening are slim, but I think in the end its good practice.
We can use one more trick for this.
for (i = 5; i > 0; i--)
I suppose most of the compilers optimize the loops like this.
I am not sure. Someone please verify.
Ultimately, the deciding factor as to what is more efficient is neither the language nor the compiler, but rather, the underlying hardware. If you’re writing code for an embedded microcontroller like an 8051, counting up vs. counting down, greater or less than vs. not equals, and incrementing vs. decrementing, can make a difference to performance, within the very limited time scale of your loops.
While sufficient language and compiler support can (and often do) mitigate the absence of the instructions required to implement the specified code in an optimal but conceptually equivalent way, coding for the hardware itself guarantees performance, rather than merely hoping adequate optimizations exist at compile time.
And all this means, there is no one universal answer to your question, since there are so many different low-end microcontrollers out there.
Of much greater importance, however, than optimizing how your for loop iterates, loops, and breaks, is modifying what it does on each iteration. If causing the for loop one extra instruction saves two or more instructions within each iteration, do it! You will get a net gain of one or more cycles! For truly optimal code, you have to weigh the consequences of fully optimizing how the for loop iterates over what happens on each iteration.
All that being said, a good rule of thumb is, if you would find it a challenge to memorize all the assembly instructions for your particular target hardware, the optimal assembly instructions for all variations of a “for” loop have probably been fully accounted for. You can always check if you REALLY care.
I see plenty of answers using the specific code that was posted, and integer. However the question was specific to 'for loops', not the specific one mentioned in the original post.
I prefer to use the prefix increment/decrement operator because it is pretty much guaranteed to be as fast as the postfix operator, but has the possibility to be faster when used with non-primitive types. For types like integers it will never matter with any modern compiler, but if you get in the habit of using the prefix operator, then in the cases where it will provide a speed boost, you'll benefit from it.
I recently ran a static analysis tool on a large project (probably around 1-2 million lines of code), and it found around 80 cases where a postfix was being used in a case where a prefix would provide a speed benefit. In most of these cases the benefit was small because the size of the container or number of loops would usually be small, but in other cases it could potentially iterate over 500+ items.
Depending on the type of object being incremented/decremented, when a postfix occurs a copy can also occur. I would be curious to find out how many compilers will spot the case when a postfix is being used when its value isn't referenced, and thus the copy could not be used. Would it generate code in that case for a prefix instead? Even the static analysis tool mentioned that some of those 80 cases it had found might be optimized out anyway, but why take the chance and let the compiler decide? I don't find the prefix operator to be at all confusing when used alone, it only becomes a burden to read when it starts getting used, inline, as part of a logic statement:
int i = 5;
i = ++i * 3;
Having to think about operator precedence shouldn't be necessary with simple logic.
int i = 5;
i++;
i *= 3;
Sure the code above takes an extra line, but it reads more clearly. But with a for loop the variable being altered is its own statement, so you don't have to worry about whether it's prefix or postfix, just like in the code block above, the i++ is alone, so little thought is required as to what will happen with it, so this code block below is probably just as readable:
int i = 5;
++i;
i *= 3;
As I've said, it doesn't matter all that much, but using the prefix when the variable is not being used otherwise in the same statement is just a good habit in my opinion, because at some point you'll be using it on a non-primitive class and you might save yourself a copy operation.
Just my two cents.
On many architectures, it is far easier to check whether something is zero that whether it is some other arbitrary integer, therefore if you truly want to optimize the heck out of something, whenever possible count down, not up (here's an example on ARM chips).
In general, it really depends on how you think about numbers and counting. I'm doing lots of DSP and mathematics, so counting from 0 to N-1 is more natural to me, you may be different in this respect.
FORTRAN's DO loop and BASIC's FOR loop implemented < (actually <=) for positive increments. Not sure what COBOL did, but I suspect it was similar. So this approach was "natural" to the designers and users of "new" languages like C.
Additionally, < is more likely than != to terminate in erroneous situations, and is equally valid for integer and floating point values.
The first point above is the probable reason the style got started, the second is the main reason it continues.
I remember one code segment where the i was getting incremented by 2 instead of 1 due to some mistake and it was causing it to go in infinite loop. So it is better to have this loop as shown in the first option. This is more readable also. Because i != 5 and i < 5 conveys two different meaning to the reader. Also if you are increasing the loop variable then i<5 is suppose to end some point of time while i != 5 may never end because of some mistake.
It is not good approach to use as != 5. But
for (int i =0; i<index; ++i)
is more efficient than
for(int i=0; i<index; i++)
Because i++ first perform copy operation. For detailed information you can look operator overloading in C++.
Is there any performance difference between the for loops on a primitive array?
Assume:
double[] doubleArray = new double[300000];
for (double var: doubleArray)
someComplexCalculation(var);
or :
for ( int i = 0, y = doubleArray.length; i < y; i++)
someComplexCalculation(doubleArray[i]);
Test result
I actually profiled it:
Total timeused for modern loop= 13269ms
Total timeused for old loop = 15370ms
So the modern loop actually runs faster, at least on my Mac OSX JVM 1.5.
Your hand-written, "old" form executes fewer instructions, and may be faster, although you'd have to profile it under a given JIT compiler to know for sure. The "new" form is definitely not faster.
If you look at the disassembled code (compiled by Sun's JDK 1.5), you'll see that the "new" form is equivalent to the following code:
1: double[] tmp = doubleArray;
2: for (int i = 0, y = tmp.length; i < y; i++) {
3: double var = tmp[i];
4: someComplexCalculation(var);
5: }
So, you can see that more local variables are used. The assignment of doubleArray to tmp at line 1 is "extra", but it doesn't occur in the loop, and probably can't be measured. The assignment to var at line 3 is also extra. If there is a difference in performance, this would be responsible.
Line 1 might seem unnecessary, but it's boilerplate to cache the result if the array is computed by a method before entering the loop.
That said, I would use the new form, unless you need to do something with the index variable. Any performance difference is likely to be optimized away by the JIT compiler at runtime, and the new form is more clear. If you continue to do it "by hand", you may miss out on future optimizations. Generally, a good compiler can optimize "stupid" code well, but stumbles on "smart" code.
My opinion is that you don't know and shouldn't guess. Trying to outsmart compilers these days is fruitless.
There have been times people learned "Patterns" that seemed to optimize some operation, but in the next version of Java those patterns were actually slower.
Always write it as clear as you possibly can and don't worry about optimization until you actually have some user spec in your hand and are failing to meet some requirement, and even then be very careful to run before and after tests to ensure that your "fix" actually improved it enough to make that requirement pass.
The compiler can do some amazing things that would really blow your socks off, and even if you make some test that iterates over some large range, it may perform completely differently if you have a smaller range or change what happens inside the loop.
Just in time compiling means it can occasionally outperform C, and there is no reason it can't outperform static assembly language in some cases (assembly can't determine beforehand that a call isn't required, Java can at times do just that.
To sum it up: the most value you can put into your code is to write it to be readable.
There is no difference. Java will transform the enhanced for into the normal for loop. The enhanced for is just a "syntax sugar". The bytecode generated is the same for both loops.
Why not measure it yourself?
This sounds a bit harsh, but this kind of questions are very easy to verify yourself.
Just create the array and execute each loop 1000 or more times, and measure the amount of time. Repeat several times to eliminate glitches.
I got very curious about your question, even after my previous answer. So I decided to check it myself too. I wrote this small piece of code (please ignore math correctness about checking if a number is prime ;-)):
public class TestEnhancedFor {
public static void main(String args[]){
new TestEnhancedFor();
}
public TestEnhancedFor(){
int numberOfItems = 100000;
double[] items = getArrayOfItems(numberOfItems);
int repetitions = 0;
long start, end;
do {
start = System.currentTimeMillis();
doNormalFor(items);
end = System.currentTimeMillis();
System.out.printf("Normal For. Repetition %d: %d\n",
repetitions, end-start);
start = System.currentTimeMillis();
doEnhancedFor(items);
end = System.currentTimeMillis();
System.out.printf("Enhanced For. Repetition %d: %d\n\n",
repetitions, end-start);
} while (++repetitions < 5);
}
private double[] getArrayOfItems(int numberOfItems){
double[] items = new double[numberOfItems];
for (int i=0; i < numberOfItems; i++)
items[i] = i;
return items;
}
private void doSomeComplexCalculation(double item){
// check if item is prime number
for (int i = 3; i < item / 2; i+=2){
if ((item / i) == (int) (item / i)) break;
}
}
private void doNormalFor(double[] items){
for (int i = 0; i < items.length; i++)
doSomeComplexCalculation(items[i]);
}
private void doEnhancedFor(double[] items){
for (double item : items)
doSomeComplexCalculation(item);
}
}
Running the app gave the following results for me:
Normal For. Repetition 0: 5594
Enhanced For. Repetition 0: 5594
Normal For. Repetition 1: 5531
Enhanced For. Repetition 1: 5547
Normal For. Repetition 2: 5532
Enhanced For. Repetition 2: 5578
Normal For. Repetition 3: 5531
Enhanced For. Repetition 3: 5531
Normal For. Repetition 4: 5547
Enhanced For. Repetition 4: 5532
As we can see, the variation among the results is very small, and sometimes the normal loop runs faster, sometimes the enhanced loop is faster. Since there are other apps open in my computer, I find it normal. Also, only the first execution is slower than the others -- I believe this has to do with JIT optimizations.
Average times (excluding the first repetition) are 5535,25ms for the normal loop and 5547ms for the enhanced loop. But we can see that the best running times for both loops is the same (5531ms), so I think we can come to the conclusion that both loops have the same performance -- and the variations of time elapsed are due to other applications (even the OS) of the machine.