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.
![เปิดใจ พี่ญา คนรุม หลังทัวร์ลง หนักสุดในชีวิต!! l [Nickynachat]](http://i.ytimg.com/vi/2-OJZRtclro/mqdefault.jpg)
This video should be watched by every serious Java developer
Yes
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.
thanks a lot , This video should be watched by every serious Java developer
This is a really good explaination of using CompletableFuture and parallel streams
Interesting to note that the forkJoin pool sets the number of runnables equal to the cpu cores.
Actually number of CPU cores -1
0:45
hi, when should i use Project Loom instead of Reactive
@Java can you guys please share the ppt here :) love the video
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.
amazing video Iam watching at 2023 I hope they released better mac's😂😂😂😂 20:10
Why didn't we name it 'concurrentStream' instead of 'parallelStream'?
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
Confidential?
Completablefuture is also blocking, until first task is completed second task will not start if second task depends upon first task output... Please explain
So it meant you are using the wrong way.
@@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.
beginners you can skip this exp 3+ u shud watch this