![]() However, just because its easy, doesn't mean its always a good idea, and in fact, it is a bad idea to just drop. The Stream API was designed to make it easy to write computations in a way that was abstracted away from how they would be executed, making switching between sequential and parallel easy. In any case, measure, don't guess! Only a measurement will tell you if the parallelism is worth it or not. In particular, side effects are things you really have to worry about if you go parallel. If a shared resource is used by the predicates and functions used in the process, you'll have to make sure that everything is thread-safe. Moreover, remember that parallel streams don't magically solve all the synchronization problems. In your example, the performance will anyway be driven by the synchronized access to (), and making this process parallel will have no effect, or even a negative one. I don't already run the process in a multi-thread environment (for example: in a web container, if I already have many requests to process in parallel, adding an additional layer of parallelism inside each request could have more negative than positive effects) I have a performance problem in the first place I have a massive amount of items to process (or the processing of each item takes time and is parallelizable) I would use sequential streams by default and only consider parallel ones if Coordinating the threads takes a significant amount of time. A parallel stream has a much higher overhead compared to a sequential one.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |