Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web Framework Benchmarks Round 4

techempower.com

Post reply on HN
Print view View original

181–190 of 358 posts

Re: Web Framework Benchmarks Round 4

#181

Post by camus »

zinxq wrote: post #178

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to the system - every little thing you do costs more. Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. That's like choosing between a farm tractor or a ferrari - and figuring if the t…

People chose language X over language Y not for performance reasons. Cost , ease of use and deployment , librairies , available programmers ,etc ... Things are more complicated than just a benchmarks. Furthermore NodeJS and raw PHP are doing quite well in the benchmarks.

Re: Web Framework Benchmarks Round 4

#182

Post by dragonwriter »

zinxq wrote: post #178

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to the system - every little thing you do costs more. Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. That's like choosing between a farm tractor or a ferrari - and figuring if the t…

> Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed.

True.

> That's like choosing between a farm tractor or a ferrari - and figuring if the tractor doesn't perform up to snuff, we'll add a spoiler

Its really not like that at all, because programming languages aren't like vehicles. Particularly, with Ruby, on typical method of optimization is finding which bits of code are bottlenecks, and then optimizing those bottlenecks, often by replacing them with C (or, if the Ruby runtime being used in JRuby, Java).

Which I guess is like having your tractor turn into a Ferrari for the parts of work that involve going long distances on a road without towing something, but I think that kind of points out how bad even using the tractor/Ferrari analogy is.

Re: Web Framework Benchmarks Round 4

#183

Post by kbenson »

trailfox wrote: post #141
freework wrote: post #119

Earlier quoted context omitted.

You can build an application in Ruby, deploy it onto 15 machines, and it will outperform the same application written in C and deployed to only one machine. Performance is more of a function of the underlying hardware than the language used to build it.

If a language is 30x less efficient than another language then you would likely need 30x more servers. Many folk are simply not prepared to spend 30x more than they need to on hardware. It's the difference between 20 servers and 600 servers. Case in point: "How We Went from 30 Servers to 2": http://blog.iron.io/2013/03/how-we-went-from-30-servers-to-2...

That's only true when you are using the full resources of one or more servers. If you are only using 1/100th of the server's resources, then being 30x less efficient still doesn't require any more servers.

That doesn't negate the point though, language performance matters at certain scales.

Re: Web Framework Benchmarks Round 4

#184

Post by zinxq »

camus wrote: post #181
zinxq wrote: post #178

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to the system - every little thing you do costs more. Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. That's like choosing between a farm tractor or a ferrari - and figuring if the t…

People chose language X over language Y not for performance reasons. Cost , ease of use and deployment , librairies , available programmers ,etc ... Things are more complicated than just a benchmarks. Furthermore NodeJS and raw PHP are doing quite well in the benchmarks.

I did say exactly that - there's plenty of good reasons for choosing them - but understanding its a tradeoff is a good idea.

In other words, although interesting (and exceedingly well done) these benchmarks should have "surprised" no one. Not even the disparity between languages.

Re: Web Framework Benchmarks Round 4

#185

Post by krg »

SkyMarshal wrote: post #179
ninjazee124 wrote: post #128

Guess Lift is not all that high performance framework that they claim it to be!

Depends on whether any Lifters have optimized it for these tests or not, which, after skimming the github repo and commit history, does not appear to be the case. Same with any of the other frameworks - some have been optimized by their fans, others are running in default configs. Techempower should add a filter to show only frameworks that have been optimized.

At this point, most of the tests were contributed/improved by the community. Not all have been reviewed by experts in that framework, and I agree that an "expert reviewed" marker would be nice.

That said, we have tried to not run anything in the "default" configs, but rather the "production deployment" configs if we could find documentation on that. Unfortunately there is a huge variability across frameworks in how good the "production deployment" documentation is.

Re: Web Framework Benchmarks Round 4

#186

Post by ricardobeat »

reactor wrote: post #36

Off all the top performers, Go seems to be the only sane choice to write a web app. Moreover it is at the sweet spot; expressive, flexible, simple, super performant, good community etc. I think it is convincing enough for me to give Go a serious look for our new app.

Check this out: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...

Javascript is also expressive, flexible, super performant and has the best and fastest-growing community around.

Re: Web Framework Benchmarks Round 4

#188

Post by candybar »

dragonwriter wrote: post #182
zinxq wrote: post #178

There should be no surprise that interpreted, dynamic languages are utterly out-gunned as compared to compiled (JIT'd or otherwise) languages. It's inherent to the system - every little thing you do costs more. Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. That's like choosing between a farm tractor or a ferrari - and figuring if the t…

> Many people choose Ruby and figure, given that premature optimization is the root of all evil, they'll optimize later if needed. True. > That's like choosing between a farm tractor or a ferrari - and figuring if the tractor doesn't perform up to snuff, we'll add a spoiler Its really not like that at all, because programming languages aren't like vehicles. Particularly, with Ruby, on typical method of optimization i…

I keep hearing about this, but do people really rewrite performance-critical parts of their web apps in C? Even if it happens to be part of some third-party library? And maintain a fork? What if that performance-critical part is dependent on other parts in a non-trivial way? It seems that an unanticipated replacement of some core functionality with a C library may involve a major rewrite and most Ruby teams may not have the expertise to do a good job maintaining a C code base any way.

Re: Web Framework Benchmarks Round 4

#189

Post by iknight »

platz wrote: post #43
cmircea wrote: post #27

Earlier quoted context omitted.

Would it be too much to ask to also run a Windows VM? Or use Mono?

http://www.techempower.com/benchmarks/#section=motivation "As with the previous question, we'd love to. We have heard tentative word from a reader/contributor that a pull request may be incoming soon that will include several .NET frameworks on Mono, which we assume will be as easy to include as any other pull request. One challenge we face is that the test infrastructure we've built assumes a Linux deployment that w…

Can you share who the Mono contributor is?

Re: Web Framework Benchmarks Round 4

#190

Post by campnic »

I think the overlooked part of this, once we step back from the natural desire to pick 'the best', is that people who care about the platforms are providing a vast set of starting examples for people looking to get started on each network. Its easy to do a side by side comparison of similar tasks across languages which is something that is very valuable and, in my experience, relatively novel. Thanks for all your amazing work!
Post reply on HN