Java 8 forEach Stream () vs. old forEach Loop
I have tried sample code with spring. And part of the code looks like this:
private List<Point> points;
long timeTakeninMilis = System.currentTimeMillis();
public List<Point> getPoints() {
return points;
}
public void setPoints(List<Point> points) {
this.points = points;
}
public void drawJava8() {
points.stream().forEachOrdered(
point -> System.out.println("Point : (" + point.getX() + ", "
+ point.getY() + ")"));
System.out.println("Total Time Taken drawJava8(): "
+ (System.currentTimeMillis() - timeTakeninMilis)
+ " miliseconds");
}
public void draw() {
for (Point point : points) {
System.out.println("Point = (" + point.getX() + ", " + point.getY()
+ " )");
}
System.out.println("Total Time Taken draw(): "
+ (System.currentTimeMillis() - timeTakeninMilis)
+ " miliseconds");
}
OUTPUT,
Jun 30, 2015 11:30:53 AM org.springframework.context.support.ClassPathXmlApplicationContext prepareRefresh
INFO: Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@7daf6ecc: startup date [Tue Jun 30 11:30:53 IST 2015]; root of context hierarchy
Jun 30, 2015 11:30:53 AM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [spring.xml]
Point = (0, 0 )
Point = (-50, 0 )
Point = (0, 50 )
Total Time Taken draw(): 70 miliseconds
Point : (0, 0)
Point : (-50, 0)
Point : (0, 50)
Total Time Taken drawJava8(): 124 miliseconds
Jun 30, 2015 11:30:54 AM org.springframework.context.support.ClassPathXmlApplicationContext doClose
INFO: Closing org.springframework.context.support.ClassPathXmlApplicationContext@7daf6ecc: startup date [Tue Jun 30 11:30:53 IST 2015]; root of context hierarchy
Why is it taking longer? Or am I doing something wrong?
I expected it to be faster or at the same speed ... Please help me understand what is the advantage of Lambda expressions?
INFO: I did it in two different programs. Times are taken from them. I've combined them here to keep it short.
source to share
Adding this as an analysis to the original poster request.
We cannot predict the complex analysis and transformation that a modern JIT compiler performs when running code. Hence, while comparative items like these are, you shouldn't be doing this by simply making two method calls.
Instead, create different sets of input samples (edge cases) and match, re-name your test cases without shutting down the JVM. In this case, for example:
for (int i=0;i<100;i++){draw(); drawJava8();}
After you get the results, find the average execution and you can safely ignore the result of the first execution as it may not have had any optimizations.
So, the conclusion you drew from your tests is not entirely correct.
source to share