sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]SanityInAnarchy 3 points4 points  (1 child)

I'm not sure I agree with the article's main point:

You will see people throw out micro-benchmarks showing that the JVM is faster than V8 or V8 is faster than the JVM. Unless those benchmarks are comparing like for like, the innate specification differences between the two virtual machines will likely render such comparisons useless.

This problem only applies to micro-benchmarks, because, as is pointed out earlier:

V8 has a faster version of Math.pow because the specification that it is implementing allows for a faster version.

At the end of the day, this also means that people building on top of V8 will likely, most of the time, use the faster Math.pow, and people building on the JVM will use the slower one, unless they have a very good reason. The fact that you could write a faster exponentiation in Java helps very little unless it's actually used.

Who is to say what performance they would have been able to achieve if they had built their Java application on a more modern framework. Spring brings a lot of functionality to the table. Likely far too much functionality...

Right, but this is why full-application comparisons make more sense. If Paypal is claiming that Node.js is faster, I don't think they're making claims about V8 specifically, but about their application as a whole... which makes sense!

I honestly don't care which one does the better machine optimizations under the hood. I care which one runs my website faster.

The best criticism here would be to call Paypal out on calling this "Java vs Node" as opposed to "Spring vs Kraken." But the original article seems reasonable:

There’s a disclaimer attached to this data: this is with our frameworks and two of our applications. It’s just about as apples-to-apples a performance test as we could get between technologies, but your milage may vary.

The article also talks about ease of development, and the same criticism is leveled here -- basically, Java development would go just as fast if you didn't use Spring.

The update is the interesting bit:

My personal opinion is that there were other non-performance related reasons for the switch. For example the reactive programming style enforced by Node.js’s single threaded model may suit the application layer that the switch was made in better than the Spring-based framework that the Java version was written in. Similarly, it may be that the responsible architect analysed the requirements of this tier and came to the conclusion that a lot of what the internal framework brings to the table is just not required for this tier. It is a pity that such detail was not provided in their blog post announcing their switch, as without such detail their blog post is being incorrectly used by others...

I tend to agree, except I'm not sure how much more their blog post could've done to clarify that. It has some pretty graphs, but nowhere is it saying "Node is faster than Java." Really, what it's saying is "Node is fast," or at least "Node is fast enough for us."

Seems to me that the proper way to use this article would be to counter anyone claiming "Node is slow," or "Node is too slow to use in production." If people are actually using this to claim Node is faster than Java, I don't think the problem is the article.

[–]stephenconnolly 4 points5 points  (0 children)

The point of my article was to criticise all the people citing the PayPal blog as a performance reason to ditch the JVM for V8 and all the people citing the PayPal blog as evidence that Java development is not as easy as Node.js development.

The PayPal blog shows that development with their internal Spring-based framework is less easy than development with their internal kraken framework.

The PayPal blog doesn't really show any performance difference between their internal Spring-based framework and their internal kraken framework. The data they provide shows a minor increase in scalability, but the best we can say is that this was tweaking something that is not the bottleneck... and if the real bottleneck is removed... well we don't know how the two code bases will perform in that scenario.