Home

News: Did Java 8 'jump the shark' with Project Lambda and interface evolution?

  1. Lambda has been long awaited and long anticipated, but some are worried that the changes required to various Java constructs, namely the interface, will lead many projects down the rabbit hole of bad programming choices and maintainable code, the exact problems Lambda was intended to address.

    Lambda, Java 8, interface evolution and laws of unintended consequences

    Threaded Messages (4)

  2. Are lambdas really faster?[ Go to top ]

    Hi, Cameron.

    I enjoyed your article but I would like to know what evidence there is of your example functional code being faster than the example traditional way.

    I have tested the code with Caliper and I find the traditional way about one third faster (note: I had to adjust the code slightly so it wasn't calling System.out.println as IO is generally slow and has no place in benchmarks). 

    Regards,

    Phillip

  3. InvokeDynamic is the key...[ Go to top ]

    Hi, Cameron.

    I enjoyed your article but I would like to know what evidence there is of your example functional code being faster than the example traditional way.

    I have tested the code with Caliper and I find the traditional way about one third faster (note: I had to adjust the code slightly so it wasn't calling System.out.println as IO is generally slow and has no place in benchmarks). 

    Regards,

    Phillip

    Hi Phillip, the key here is the way in which lambdas are invoked in Java8.  With the traditional way of passing around functionality via Annonymous Inner Classes, a class must be instantiated, allocated, garbage collected.  Using Java8 lambdas they instead use InvokeDynamic to bypass all of the extra object creation.

    Taking that for what it is, you'll see a big performance gain if you are using a lambda in a loop which iterates many times.

  4. Are lambdas really faster?[ Go to top ]

    Phillip,

    Although I'm not a big fan of functional style, it seems to me that the statement saying "filtering done in several threads is faster" makes sense. The only thing - how many elements did you have in your original array.

    My assumption that this parallelism will be beneficiall only starting from a certain amount of elements, when additional thread fork/join burden will not outweight the processing time.

    Regards,

    Denis

  5. InvokeDynamic and Autoboxing[ Go to top ]

    Hi, Craig.

    Thanks for the information about invokeDynamic, it was a good one. But what I am finding is that this saving is dwarfed by the autoboxing that comes with Lambdas. You light make a saving on invokeDynamic but then create 100 000s of Integers when you map over a moderately sized collection of ints.

    (Shameless plug alert): I present the code for my assertions on my blog at http://javaagile.blogspot.co.uk/2013/10/a-first-look-at-java-8s-lambdas.html . Please feel free to run it in Caliper on your computers and tell me what you think

    Hi, Dennis.

    Another good point and it's an area where FP really excites me. But the overhead of using threads makes it only realistic when you have fairly chunky datasets. It's just not worth it for most purposes. (Shameless plug no. 2: I did some tests of this that are available at http://javaagile.blogspot.co.uk/2013/01/is-functional-faster-in-java.html).

    Regards,

    Phillip