Two poorly written apps compared with blame for each placed on the underlying virtual machine rather than the part between the chair and the keyboard. I'd much rather compare VMs and systems with something a little more structured and open like the TechEmpower benchmarks. They still have their flaws and simplifications, but at least the source for all apps is open and you can see and contribute to them.
About PayPal's Node vs Java “fight”
11–20 of 216 posts
Re: About PayPal's Node vs Java “fight”
#12Summary: Most frameworks sux.
Wrong. PayPal refuses to use open source frameworks because of an internal culture (and self preservation interest) of some very old "architects" who really only care about being in charge of the next internal framework. The best part is they later get to showcase how much better the new one is compared to the old framework, even though it's multiples slower than the slowest open-source counterpart.
Spring is open source. From the sounds of things, they replaced Spring with a closed in-house framework.
Re: About PayPal's Node vs Java “fight”
#13Regarding the JVM performance: > Under minimum load the best page rendering time was 233ms Regarding the node.js performance: > Under minimum load the best page rendering time was 249ms What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going t…
The fact that both implementations are ridiculously slow tells me to look for commonalities. In this case, how much do you want to bet that there are some truly scary, gigantic and all-but-incomprehensible stored procedures underlying everything?
Re: About PayPal's Node vs Java “fight”
#14This was a good read. Minor nitpick, given the author's stress of not comparing apples to oranges I think the motivating anecdote on protein folding struck a dissonant cord. A fair comparison would have been a profile guided optimization with comparably aggressive compile optimization flags.
For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up time.
Java can indeed be very fast, and in my opinion JVM is the one of the most optimized VMs that we have now. That said Java code beating a C or a C++ code on a CPU bound task raised an eyebrow. In my experience Java usually gets to the 80% speed of C++ quite easily but at a cost of 2.5 to 3.5 the memory. For these types of applications memory tends to be an expensive resource. For our number crunching server, 80% of its cost is sunk in the RAM.
Re: About PayPal's Node vs Java “fight”
#15Regarding the JVM performance: > Under minimum load the best page rendering time was 233ms Regarding the node.js performance: > Under minimum load the best page rendering time was 249ms What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going t…
> Language choice is no where near as important as your DB-access patterns (and more generally DB performance, caching, etc).
i'm pretty sure the paypal node app does not directly access the db , the node app talks to a private api.
Re: About PayPal's Node vs Java “fight”
#16Damn, paypal really suck at making fast sites.
Re: About PayPal's Node vs Java “fight”
#17This was a good read. Minor nitpick, given the author's stress of not comparing apples to oranges I think the motivating anecdote on protein folding struck a dissonant cord. A fair comparison would have been a profile guided optimization with comparably aggressive compile optimization flags. For these types of problems the profile characteristic is fairly static, so there is hardly ever a need to pay for the warm up…
I debated including that example, but at the end the point I was making is that the JVM can be faster than native code in some cases... this case had static allocation of data and the calculations could benefit from MMX instructions when available, plus there was a logical unrolling that I think it was able to infer from code path analysis
Re: About PayPal's Node vs Java “fight”
#18Earlier quoted context omitted.
Wrong. PayPal refuses to use open source frameworks because of an internal culture (and self preservation interest) of some very old "architects" who really only care about being in charge of the next internal framework. The best part is they later get to showcase how much better the new one is compared to the old framework, even though it's multiples slower than the slowest open-source counterpart.
Spring is open source. From the sounds of things, they replaced Spring with a closed in-house framework.
"Based on Spring" is not Spring. I worked there for a bit, they called it Sparta, and its appeal to the top tech brass was they could restrict which objects are available for use in the library they provided for you. The subtle message behind it was, we can hire anyone as long as we limit what they can do.
Re: About PayPal's Node vs Java “fight”
#19Regarding the JVM performance: > Under minimum load the best page rendering time was 233ms Regarding the node.js performance: > Under minimum load the best page rendering time was 249ms What the heck are they doing that takes 250ms that could possibly be app code related? That's a lot of CPU usage if its actually doing CPU-bound work. Since these are web apps that's obviously not the case. The request time is going t…
The fact that both implementations are ridiculously slow tells me to look for commonalities. In this case, how much do you want to bet that there are some truly scary, gigantic and all-but-incomprehensible stored procedures underlying everything?
No bet. :)
Re: About PayPal's Node vs Java “fight”
#20Summary: Most frameworks sux.
Wrong. PayPal refuses to use open source frameworks because of an internal culture (and self preservation interest) of some very old "architects" who really only care about being in charge of the next internal framework. The best part is they later get to showcase how much better the new one is compared to the old framework, even though it's multiples slower than the slowest open-source counterpart.
Their node.js "framework" is really just a couple modules sitting on top of express, and they are all open-source.