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

271–280 of 358 posts

Re: Web Framework Benchmarks Round 4

#271

Post by justincormack »

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…

Openresty is doing pretty well with Lua and despite the fact it uses LuaJIT it is actually interpreted and the JIT compiler is not used (that will change eventually). Ruby is just slow, as is PHP.

Re: Web Framework Benchmarks Round 4

#272

Post by gionn »

ihsw wrote: post #95

It's very depressing to see Symfony2 at the bottom of these lists. Although there are quite a few performance optimizations that can be done to improve this, there are few excuses for such poor performance by default.

https://github.com/TechEmpower/FrameworkBenchmarks/issues/23...

Re: Web Framework Benchmarks Round 4

#273

Post by mightybyte »

mercurial wrote: post #228
LukeHoersten wrote: post #218

The Haskell Snap Framework has a new http server in the works. It's completely rewritten on a new library called io-streams with performance in mind. Initial benchmark results look promising. http://snapframework.com/blog/2013/03/05/announcing-io-strea...

On the other hand, I'm genuinely surprised the current stable version is not doing any better.

This benchmark probably has more to do with the performance of the JSON serialization and database libraries than with web framework performance.

Re: Web Framework Benchmarks Round 4

#274

Post by IanChiles »

njharman wrote: post #174
IanChiles wrote: post #79

Earlier quoted context omitted.

After seeing this, and having been a long time Sinatra devotee (I thought Sinatra was pretty fast until I saw these benchmarks), I'm considering picking up Go or Lua (OpenResty) at some point in the future. I'm blown away by the speed differences.

Have you ever deployed a Sinatra (or any) project that failed cause it was too slow / could not scale? Avoiding preoptimization applies just as much to frameworks.

Not at all. It's just that if there's a faster way to do it, I might as well pick it up for future projects.

Re: Web Framework Benchmarks Round 4

#275

Post by IanChiles »

trailfox wrote: post #85
IanChiles wrote: post #79

Earlier quoted context omitted.

After seeing this, and having been a long time Sinatra devotee (I thought Sinatra was pretty fast until I saw these benchmarks), I'm considering picking up Go or Lua (OpenResty) at some point in the future. I'm blown away by the speed differences.

You'd probably be better of with Scalatra then...

Scalatra looks pretty neat as well - might need to give it a try as well.

Re: Web Framework Benchmarks Round 4

#276

Post by room271 »

terhechte wrote: post #157
kclay wrote: post #22

Why I'm still using Play! these results are disappointing once again, atleast beat node.js. Go is looking great though.

I've dabbled a bit with Play, but found it too slow (with Scala). Have a look at Scalatra or, if you don't need a full blown framework, Spray

Or Unfiltered which performed very well in the tests too.

Re: Web Framework Benchmarks Round 4

#277

Post by matt2000 »

phillmv wrote: post #112
hippich wrote: post #57

Whenever I hear "Java" I also get association "slow". But looking into this list - java web frameworks doing incredible job!

Because it is slow. Compared to C/C++/langs without runtimes [albeit with JIT compilation, for long running applications this is becoming a non issue]. Compared to the current crop of dynamic language interpreters, waaaay more engineering time and talent has been poured into optimizing the jvm. People I think forget that Java was a more user friendly C++; the price you paid was somewhat slower apps, but that's OK bec…

Feels like Java is the new C, C is the new ASM (performance wise at least). I've been doing this long enough that when I started using Java it was too slow for "anything serious", now it's the coice for performance. Definitely feels weird.

Re: Web Framework Benchmarks Round 4

#278

Post by kbenson »

voidlogic wrote: post #225
kbenson wrote: post #175

Earlier quoted context omitted.

I don't consider the Go size pretty small. Mojolicious[1], Dancer[2] and Kelp[3] have set the bar for small code size for me. Not sure yet if there are smaller ones (note that there are no other files required for those apps, period) In the same vein, Lua's OpenResty[4] looks good, as do Tornado[5], Flask[6] and Bottle[7] (although you need to tease the raw/ORM methods apart to get an idea for the last two). And of c…

>>I don't consider the Go size pretty small. You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked). Also, Go is statically typed = win

> You realize that Go implements the new template test right? Your linked ones do not (at least the ones I spot checked).

hello.go uses more lines defining variables and types than the entirely of many of the alternatives I posted. Obviously they will be a little longer if they implement the fortune handler, but I doubt that will really make much of a difference.

> Also, Go is statically typed = win

I'm not sure what that has to do with implementation size (which is the only thing I was addressing), but feel free to make a case.

Re: Web Framework Benchmarks Round 4

#279

Post by rorrr2 »

oberhamsi wrote: post #143
cmircea wrote: post #28

Earlier quoted context omitted.

Probably because all those big frameworks have to initialize everything for every request. Parsing, connections, configuration, you name it.

Is there no php environment with a persistent server? Are they really all doing per request startup?

Well, you could daemonize a PHP process, which would listen to some port, and parse the requests. It's like implementing your web server in PHP.

The problem with it is, one request can bring the whole thing down.

Post reply on HN