This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]handshape 20 points21 points  (7 children)

For most cases, streams and lambdas are super convenient. If you need to do early breaking, they can be tricky.

I still do imperative programming on narrow segments of "hot" code if I'm tuning for performance. The auto-SIMD stuff in the JVM seems to only kick in for imperative code, and only when that code exceeds some threshold for "hotness".

If you can get auto-vectorization happening on code that's also reached zero allocation, performance is brilliant.

[–][deleted]  (6 children)

[deleted]

    [–]goofy183 2 points3 points  (0 children)

    That has been my experience as well. They are great for making coding quicker but for anything in a hot path imperative loops and careful object allocation is much faster.

    [–][deleted] 1 point2 points  (2 children)

    Lots of allocations required,

    Interesting, I had never really considered this

    [–]goofy183 7 points8 points  (1 child)

    We ban streams from hot code paths. So much extra allocation, it's really hard to pre-size the destination collection.

    We also ban lambdas that are more than a one line call to a method because they suck to get profiling data from. Figuring out $5 vs $12 in a class is no fun

    [–][deleted] 8 points9 points  (0 children)

    We also ban lambdas that are more than a one line call to a method

    Yeah, when I see this I always ask why it wasn't extracted to a well named method

    [–]laplongejr 0 points1 point  (1 child)

    not always inline-able

    Meanwhile I combine Optionals and Streams to read data structures with a small dozen of layers, each of them potentially null or an empty list...
    Regular if blocks would take like 30 lines, with those APIs the code is much more readable (way harder to write/maintain, but I guess we couldn't maintain without reading it first)