Here is a nice example, taking advantage of the ease of going parallel. Apparently the performance without parallel will also further improve. http://blog.hersen.name/blog/2013/10/01/project-lambda-it-was-worth-the-wait/
Hervé Sent from my iPad > On 4 oct. 2013, at 00:20, David Grieve <[email protected]> wrote: > > And what about Stream? I like the declarative code that comes from using > Stream and I can see places in the code where Stream could be used, but I > wonder about its performance relative to iterators and/or enhanced for loops. > > On Oct 3, 2013, at 4:45 PM, Richard Bair <[email protected]> wrote: > >>> Hello, OpenJFX Community. >>> >>> There's a question about using Java 8 features in FX. >>> >>> I've been working on the support for InputMethods in JFXPanel which is an >>> important feature for many users who speak hieroglyphic languages. >>> The issue is tracked under: https://javafx-jira.kenai.com/browse/RT-13248 >>> >>> In order to have a high-quality support we need to change >>> javafx.scene.input.InputMethodRequests interface and introduce 3 new >>> methods. This is not needed for pure FX applications right now, but >>> absolutely required for InputMethods in the JFXPanel. However, the >>> interface is public and it was present since FX2.0, so changing it would >>> become a breaking change. So the only way to avoid the problem is using the >>> default methods. Those would return some stub values, the JDK is OK with >>> that, as it would not crash or throw exceptions, but text composition would >>> not work correctly. >>> >>> I know that we want to avoid using the Java 8 features in the JFX-8, so I >>> wanted to ask - is it OK to use the default methods here? >>> >>> >>> If you are staying away from JDK8 features for the JFX78 backport, don't >>> worry. There are more issues with new JDK8 APIs than with the new language >>> features. >>> >>> For example there were default methods put into some collections classes >>> that we solved by pushing them down to the first implements. But the Date >>> and Time picker depends on the new time package. The threeten backport >>> won't be updated until after 8 ships, so that has been removed so far. >>> >>> I'de be interested to know what a wholesale lamdaization would result in >>> speed wise and code size wise (both source and compiled). From what I can >>> tell the IDEs can lambda and de-lambda fairly easily, so it jsut makes the >>> backport more of a busy work proposition. If there were performance gains >>> it would also make a great front page story in the next java magazine or a >>> case study.. >> >> After having used Lambda's for JavaOne, I'd love to make the conversion, >> even if in the end the performance was the same, because the savings in >> noise in the Java files is so big. At one time I just took the concurrent >> classes and lambda-ized them to measure the impact on those classes. You >> could maybe pick a package and just lambda-ize that one package and see what >> happens in terms of size reduction. We might see: >> >> + A reduction in the overall class size (not pack-200'd) >> - An increase in startup time (have to spin up synthetic classes created >> at usage time) >> +/- And increase or decrease in performance >> + A decrease in source code >> >> It would be interesting to get some data for these points and see what >> effect lambda's have. Especially if an IDE can just do it in bulk… >> >> Richard >
