I enjoyed this, I do a bit of parallel stream processing myself here and there but still learned a few things here. The speaker really packs a lot of good info into this talk.
I'm a bit confused - Kenneth said that parallelism is not worth it on simple operations like sums even on 10 millions of elements - I've tried immediately with JMH with array of one million random elements just sum() of stream and parallel was ten times faster..
I'm not really sure about this but I think he was talking strictly about primitives. I don't know about JMH but if the Array you're testing is for example of type Integer, the autoboxing might have a pretty significant perfomance penalty. Thus making parallelStream worth it again.
he explained in the beginning that "concurrency" is potential, meaning it's not guaranteed it will happen, while parallelism means that tasks will always run in parallel
Completablefuture is also blocking, until first task is completed second task will not start if second task depends upon first task output... Please explain
@@soyphea8697 I think Deepak means the part where he is creating a completablefuture, calling the getRemote synchronously and than completing the cf with the result. That is blocking, it is waiting for the getRemote to finish. But it is not the CF that is blocking, it is the direct call to the getRemote.
he explained in the video that the advantages of using CompletableFuture over Future is that, by chaining CompletableFutures one after the other, you'll be sure they will run in the order that you declared them in the "pipeline". unlike the case of Future, where you need to check isDone() billions of time before you can proceed with other Future calls if you care about running tasks in a particular order.
