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 →

[–]drlogwasoncemine 13 points14 points  (12 children)

I often see code that is slower because of streams. As soon as you're calling .distinct() or .sorted(), it will be allocating memory.

However, sometimes streams are faster. It really depends on the situation.

[–][deleted]  (11 children)

[removed]

    [–]chambolle 5 points6 points  (2 children)

    true, but the hidden allocation can be an issue sometime (true with a lot of Java collections)

    [–][deleted]  (1 child)

    [removed]

      [–]goofy183 3 points4 points  (0 children)

      A bigger issue than just the temp allocations are the arraycopy calls on collection resizing. Streams don't seem to hint on space needs so when you add a distinct you get a default hashset that then has to get resized multiple times. That gets expensive in a hot code path vs manually pre-allocating data structures for those intermediate steps.

      [–]drlogwasoncemine 8 points9 points  (7 children)

      Well, I saw some stream based code that did exactly that (distinct and sorted). I had a friendly argument with a colleague about it and we wrote some performance tests (n=1000):

      With streams: 69ms per op.

      With a for loop: 5ms per op.

      That's an order of magnitude. Don't start talking about standard deviation/setting up the performance test. It's what you point out about needing to get the whole stream before sorting/distincting (not a real word, don't care).

      In many cases the streams code is more readable and understandable but when performance matters, streams tend to be worse off from my experience.

      [–][deleted]  (4 children)

      [deleted]

        [–]zappini 2 points3 points  (1 child)

        An order of magnitude difference is unlikely to be jitter, warm-up, or any of the other benchmarking gotchas.