Win a copy of Rust Web Development this week in the Other Languages forum!

Derc Zbrojvic

Greenhorn
+ Follow
since Jun 15, 2016
Cows and Likes
Cows
Total received
1
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
1
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Derc Zbrojvic

Rob Spoor wrote:One warning about using parallel streams: if I recall correctly, parallel streams are executed in the common ForkJoinPool. That does not have unlimited capacity...


Pros and cons everywhere :-) Thanks for pointing out some implications.
8 months ago
I don't see this obvious topic being mentioned by others, but PARALLEL streams can speed up an operation on a larger set of data considerably. (An "easy" way to do parallelism.) It can do this because of the functional style of operations in streams - a set of operations on one element is independent from the operations on all the other elements.

One practical example: I have a utility searching for a certain filename recursively in a directory tree (expensive disk reads). This was sped up dramatically "simply" by moving from for() to .stream().parallel(). (I quote simply because the operations did take some rewriting for the declarative style.)

Parallelism does its thing with some processing overhead, which only pays off for larger data sets, so if in doubt I construct some experiment to determine if this would be worth it for my specific data elements and the operations on them. My very rough rule-of-thumb is that with fairly simple/quick operations I should consider parallelism from 100 elements and upwards (yes, that small). If operations are time consuming, even less may be appropriate. (I think for simple/quick operations on less than 100 elements, it's hardly worth it to worry about the difference between loops and (sequential) streams unless profiling shows a bottleneck - as per others' posts.) Again, all this is very dependant on each specific case's details, so if in doubt, do the benchmarking.

As an aside, I started doing some work in Clojure a few monts ago. Functional operations on collections are the default way things happen here, so that part is very familiar to someone having used streams. It is interesting how this functional approach, with the benefits of immutability for parallelism, has changed my thought processes around constructing algorithms. (I loved the elegance of the compact expressivity of streams when Java 8 came out, and Clojure has the same sort of expressivity for the WHOLE language.) Still, if performance is your priority this environment is probably not your first choice... yet.
8 months ago

Campbell Ritchie wrote:

Derc Zbrojvic wrote:. . . Python is interpreted and thus slower . . .

What makes you think that interpreted languages are slower than compiled languages?


Interpreters do not have the scope that compilers have (else they would be compilers), or the execution metrics that VMs may provide them with (yet?). So they can't really optimize as much as JIT or native compilers.

The top 6 results of this search makes me think so too, because they say so (I haven't bothered to look at more pages).

Anyhow, that was the conventional wisdom (general rule of thumb) taught 30 years ago, and I'd be pleasantly surprised if that gap would be narrowed. But it won't be, because the drawback that make interpreters slow on execution, is at the same time their strength at deployment time (no compilation steps).

All this is not to say that interpreters can't be faster in some very well defined specific areas (as one of the pages from the search point out - the only one bothering to do tests). And if your interpreted application builds off that niche strengths, the more power to you.

I'm also watching with interest the rise in use, popularity, and remuneration (especially outside the US) for Python in comparison to Java, even though Python is interpreted and thus slower than Java. It seems very likely to me that it can be a "Java killer" by attracting new and existing players in lieu of Java, especially because of its reputation of being easier to use. (As a long-time Java dev, I won't contest that.) So that would tell me that the world still has lots of room for non-performance-critical but quick-to-rollout projects...

Then again, I'm personally of a skeptical mind, and the above annual surveys (however valid their methodology and conclusions may be... or not) and their purported proof of the rise in both Rust and Python's popularity have received a lot of PR attention in promotion of the respective languages - Slashdot, Coderanch (ha) and some other blogs come to mind. Meanwhile, in my country, mobile networks, banks, German luxury car makers, and a bunch of other big money enterprises still have a high demand for Java developers, and those systems are pretty entrenched and are not going anywhere soon  

As a last remark, it is my personal opinion that the industry fixates a little bit too much on languages and the productivity gains to be had from them, and quite too little on the overall productivity gains that can be had from information availability through proper documentation systems, maintainability through coding practices, quality through proper testing, code reviews and constant skills+experience upgrading, and other organizational factors that happen on a higher level than coding. Unfortunately (in my country at least) it would seem that coders are simply seen as fungible production units with a fixed productivity that should be swapped in and out as the need demands  

Campbell Ritchie wrote:What do the colons (“:”) mean?


Just placeholders for other lines of code not pertinent to the question (vertical version of the ellipsis "..." ). You'd have statements there to e.g. read data from the DB, construct a BufferedImage, etc.
5 years ago
This is such an old question Just adding a simple example of a servlet GET method handler (Java8), for reference.
5 years ago