While we’re drawing ever closer to Java 9, and even hearing about features in Java 10, many of us are still working with an older version. Even if your project has technically adopted Java 8, and even if you’re using it when coding new features, it’s likely that the majority of your code base is still not making the most of what’s available in Java 8 - features like Lambda Expressions, the Streams API, and new Date/Time. And this is a shame, since Java 8 provides not only nicer syntax for developers, but (usually) better application performance.
In this presentation, Trisha will:
- Highlight the performance benefits of using Java 8 - after all, you’ll probably have to persuade “The Management” that tampering with existing code is worthwhile
- Demonstrate how to identify areas of code that can be updated to use Java 8 features, and how to pick which changes will give you the most benefit
- Demonstrate how to automatically refactor your code to make use of features like lambdas and streams
- Cover some of the pros and cons of using the new features - including suggestions of when refactoring may NOT be the best idea.
The IntelliJ-specific features of some of the refactoring shown are covered in my Migrating to Java 8 tutorial.
Article: Why Java 8
Video and Research: Building a Java 8 Application
The performance tests that were written and run specifically for this talk are in the j8-morphia-perf-tests repository
Article: Java performance tutorial: How fast are the Java 8 streams? - Angelika Langer Notable Quotes:
Again, the for-loop is faster that the sequential stream operation, but the difference on an ArrayList is not nearly as significant as it was on an array.
You will find that there is no measurable difference any more between for-loop and sequential stream if the functionality is heavily cpu bound.
The point to take home is that sequential streams are no faster than loops. If you use sequential streams then you don’t do it for performance reasons; you do it because you like the functional programming style.
The reality check via our benchmark yields a ratio (sequential / parallel) of only 1.6 instead of 2.0, which illustrates the amount of overhead that is involved in going parallel and how (well or poorly) it is overcompensated (on this particular platform).
With this in mind it is fair to say that the performance model of streams is not a trivial one
…you need to benchmark a lot in order to find out for a given context whether going parallel is worth doing or not.
The realisation is: Yes, parallel stream operations are easy to use and often they run faster than sequential operations, but don’t expect miracles. Also, don’t guess; instead, benchmark a lot.
Article: Benchmark: How Misusing Streams Can Make Your Code 5 Times Slower - interesting comparison of different iteration styles. Also shows that things like boxing might add more cost than streams (but that you don’t realize you’re boxing)
Article: Stream Performance - some interesting benchmarks based on Angelika Langer’s article
Article: Follow up on Stream Performance
Date And Time
I used a bunch of techniques to produce the benchmarks on the talk. I’d like to summarize them more thoroughly when I get a chance, but for now here’s my background reading: