This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Well, it's not *that* surprising - it's typical code, so the JVM probably got optimized for it.
Moving to our Performance forum...
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Note that the two loops use a different range of values for i: the first is 0...49999, while the second is 50000...1. In most cases, you'd have to change the test in the second one to be > -1 or >= 0, anyway -- so now you have to go off and time it again...
This is proved old mathametical algorithm that decreasing a number is faster then Increasing a number and the another fatcor is about zero flag. which is easier then to compare every time you increase the number and then compare it to maximum value....
Joined: Apr 25, 2006
Ernest, The number of iterations performed by both the loops is same whether u go from 0 - 49999 or 50000 - 1.
Bjorn, When we tried executing the loops without System.out.print() statements, the time taken is displayed as 0 in both cases.
The number of iterations performed by both the loops is same whether u go from 0 - 49999 or 50000 - 1.
Indeed, I didn't imply otherwise. But the usefulness of the loop index differs: if you're going to use it as an array index, or an argument to List.get(), for example, then in the second case you'd need to either change the loop test or subtract 1 from the index before using it. What I'm saying is that in any real program, this may add additional overhead, and as long as you're microbenchmarking, you need to consider this.
Also, you need to read up on how HotSpot works before doing any kind of benchmark like this. If you put the loops in a separate method and invoke them multiple times, you'll see the performance improve. Just running something like this once in a test application gives an inaccurate impression of how it will act in a real program.
Joined: Jul 11, 2001
Originally posted by Ernest Friedman-Hill:
Almost exactly the same lines are printed in both cases, but in a different order.
Case 1 prints "l"s, case 2 "m"s. With a non-fixed font, the "m"s are likely to produce more line breaks...
author and iconoclast
Originally posted by Ankur Sharma: This is proved old mathametical algorithm that decreasing a number is faster then Increasing a number and the another fatcor is about zero flag. which is easier then to compare every time you increase the number and then compare it to maximum value....
I don't think that there is any truth in it, at least for Java.
If possible, please run the test yourself and see. Maybe you could post the results here...
Yes thank you Isuru. System.out is a blocking call or at least not thread friendly. Im not sure what was meant to be tested in the original post. The speed of the loop operation or the speed of repeated calls to System.out?
If one or the other were faster, it would be retarded by the call to System.out. Isuru's example removes this issue.