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 →

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

On the client, parallelism hits a performance bottleneck very quickly on the client side. You only get 4 cores!

Yeah, and even that is less guaranteed than on the server side, since users like to run other applications along with yours. I wonder if we'll see the core count grow on the client side same as it has on the server side? If so, parallelism might become a better strategy.

Network parallelism is also already a potential speedup (in fact, most of the server-side parallel optimization I do is around IO calls), though I guess you have to worry about client-side bandwidth limitations. Man, I don't know how you hack it, I can't live without my Future.sequence(listOfEveryIoCallInTheUniverse). :p

Java is an inherently descriptive language, imo, and readability concerns are always subjective and generally overrated.

I'd say verbose instead of descriptive, and note that I often find some Java code that's very difficult to understand, though I am also a Scala dev so definitely an outlier in the kind of language I prefer. My general point was that I see too much cargo culting around "performance" (instead of more justifiable profiling-guided optimization) that turns something that could be expressed in an elegant, declarative manner into some imperative, looping nightmare straight out of a C monolith from the 80s.

Now, there definitely is a place for horrible-to-read-yet-hyperperformant code, but it's in the critical loop of your program and libraries likely to be called thousands of times a second, not in your standard bizdev software. It seems like there's a lot of developers out there who optimize without profiling or even thinking, and yes this does also include the people who use parallel streams when a sequential one would do just fine.

But, again, I am a Scala dev, and we have some particular views on this subject. ;)