Hacker News Reader

Comment by wulczer | Hacker News Reader

From the linked blog post:

  Do these results have any real world value?
  
  Probably not. (...)

Kind of sums it up. It's fun to play around with web frameworks and draw some bar charts, but please don't take this seriously. And definitely don't say "X is slower than Y" because of this.

Things like that always remind me of this great quote by Tom Lane (source: http://en.wikipedia.org/wiki/Tom_Lane_%28computer_scientist%...):

  On idiotic benchmark comparisons "Try to carry 500 people
  from Los Angeles to Tokyo in an F-15.
  No? Try to win a dogfight in a 747. No? But they both
  fly, so it must be useful to compare them... especially
  on the basis of the most simplistic test case you can
  think of. For extra points, use *only one* test case.
  Perhaps this paper can be described as "comparing an F-15
  to a 747 on the basis of required runway length".

View on HN

The DB Query test is pretty interesting, actually. It draws results into a much closer range, and shows that your bottleneck for WebApp/DB style apps will probably be your database.

Yeah, especially when you take into account that some of them are using a proper ORM and others are just using straight SQL queries. Sinatra looks twice as fast as Rails at DB based pages, but if they through in ActiveRecord in the Sinatra app it might be even closer.

> Yeah, especially when you take into account that some of them are using a proper ORM and others are just using straight SQL queries. Sinatra looks twice as fast as Rails at DB based pages, but if they through in ActiveRecord in the Sinatra app it might be even closer.

Absolutely. It's also true the other way - you don't have to use ActiveRecord with Rails, or the native ORM with Django, etc.

Of course, we already know that these benchmarks don't really have any parity, but they're interesting at a very high level as long as you understand why one might be faster.

PS: A more complex test would be nice, though - at a cursory glance, Django's ORM doesn't appear to be as slow as it used to be/is often attributed to be.

I agree. High-traffic websites are running on many of these frameworks. As long as several companies have scaled the frameworks in question, it's better to just choose the one that makes you more productive.

When building a company it's also good to choose something your team-members know and you can recruit for.

I mostly agree with you but there's a touch of real world value here... I mean, once you start adding code to 'hello world' it's not going to get faster. So, if you have an app with some stringent perf requirements, this would tell you if you can even really start with any of these frameworks.

For that same reason, I think metrics on how much RAM they settle in at would also be interesting. They could disqualify some frameworks from RAM-constrained requirements right away (ex. if you're building some hardware with an embedded-but-sophisticated web ui).

Good traffic for the blog though. Traffic is quite... valuable these days.

Reply on news.ycombinator.com