91–100 of 241 posts
Earlier quoted context omitted.
I agree, I would like to see C# Mono included as well. People might also want to see C# .NET, but I don't think that is applicable here because we are talking about 64-bit Linux (the dominate internet platform) here.
Sorry I don't understand why it's not applicable? Mono is how you run C#/F#/.NET on Linux?
I wish Lua was tested in the benchmarks. In particular, Lua-CJSON [1] [1] http://www.kyne.com.au/~mark/software/lua-json-performance.h... (I know, everyone wishes their favorite language was represented and not all can be tested. I'm just posting this in case the OP does a "Round 3") EDIT: fix typo
It's a useful data point to know the speed of frameworks, but what matters most to me is speed of development and whether or not I enjoy the process. Wish there was a way to benchmark those points.
Matters most? There are 100x differences here. Take two companies writing the same application, one in Spring the other in Rails. Both have easy access to knowledgable people, both are industry standard. However the Spring application would be several orders of magnitude more scalable[1]. I'd consider that to be a more important consideration over enjoying the language.
[1] All benchmarks are suspect until proven otherwise. You can write slow software in Java/C/C++, you can write fast software in Python/Ruby etc etc etc
Earlier quoted context omitted.
Sorry I don't understand why it's not applicable? Mono is how you run C#/F#/.NET on Linux?
I wasn't saying Mono wasn't applicable, I WAS saying .NET was not applicable....
Are C#/Mono web frameworks an option? Because I would love to see how http://servicestack.net fares: https://github.com/ServiceStack/ServiceStack/wiki/Real-world...
Ditto. Would be great to also compare them to .NET VM
Is anyone else alarmed to see raw PHP spanking Flask, Sinatra, and other Python/Ruby frameworks? If not, can anyone explain in layman's terms why that should be the case?
With such a trivial request handler like the one in benchmark, only a small percentage of the execution is actually taken up in the view, so all of the time you're seeing in the benchmark is pure overhead of the framework. A longer running view across all of these frameworks would cause things to even out a bit. All that being said, however, it's not an unfair comparison. After all, a benchmark of this nature should be a measure of overhead because that's really all there is to measure.
Earlier quoted context omitted.
Don't think you'd need to change any code, just pull mercurial tip and recompile go and the app.
Is 1.1 production ready? I'd feel weird about incorporating something still in a "beta" phase though.
Is anyone else alarmed to see raw PHP spanking Flask, Sinatra, and other Python/Ruby frameworks? If not, can anyone explain in layman's terms why that should be the case?
I don't know about Sinatra or anything else but I can give you the reason why Flask out of the box performs like it does. Unlike PHP Flask is threadsafe and uses locks and thread or greenlet local storage. This level of indirection adds a basic performance penalty when executed on a single threaded server like gunicorn. There are ways to change that if you think that becomes a performance problem by replacing the stack object with one that does not do dispatching and by removing the locks.
This in theory is easy to do, it's just generally not a real issue since most Flask apps will actually wait on database more than they waste CPU time.
Additionally Flask has a huge request handling overhead which will be primarily noticable in dummy benchmarks that don't do much in view functions. If you have an application that actually barely executes anything in the views you can subclass the Flask object to remove some of the functionality you normally always pay for (request processors, session initialization, message flashing etc.)
Lastly Flask has some sanity checks when Python is not run with `-O` that simplify debugging. Depending on which code paths you hit you might be paying for some of that.
In the database test the primary slowness is most likely not Flask but the way the database is configured.
Generally if you ever encounter Flask to be an actual performance problem I am more than happy to point you to ways to get more speed out of it. Generally speaking though there is not much point micro-optimizing until you notice it is a problem.
I'd like to see Lift in there if you guys do another round.