7 ms·
Once again, the Node examples are wrong. - Unnecessary parsing. - Writing strings instead of buffers (they're copied, they aren't sent as-is). - Using async.
by just2n 14y ago
Once again, the Node examples are wrong.
- Unnecessary parsing.
- Writing strings instead of buffers (they're copied, they aren't sent as-is).
- Using async. It does a lot of really nasty things, most of which break V8 optimization best practices. This is a perf benchmark, not a comparison of how concise your code can be.
- Having the main request handler in a gigantic function that will never be properly optimized by V8.
- Not getting helper functions that are clearly monomorphic warm before accepting requests.
While the code itself is what I would consider fine, when benchmarking against strongly typed compiled languages, performance concerns become important, even if you have to write ugly code.
- kaoD 14y agoOn the one hand, you're completely right. On the other hand, shouldn't real code be tested? How accurate would a ugly-optimized-code be when you SHOULD write reusable code in your real life projects?
- just2n 14y agoI wouldn't use async myself, so what's "real" code varies from person to person. This is why benchmarks like this are highly misleading. But ideally, yes. We'd be better informed to see how real world code performs rather than some idyllic perf-oriented creature.
- vanderZwan 14y agoSo do a pull request and create a node.js equivalent of the stripped editions of rails and django. I'm sure they're open to it.
- ldh 14y ago> when benchmarking against strongly typed compiled languages, performance concerns become important, even if you have to write ugly code That seems to defeat the purpose of benchmarking to begin with, or at least makes it less useful for real-world comparison.
- just2n 14y agoIt's already not an apples to apples comparison. For instance, what's in the Node examples is much the use of frameworks built to enable rapid prototyping, not built to handle the needs of performance-oriented services. So we're comparing some optimized systems designed to be used in production versus frameworks designed to be terse instead of performant.
- ldh 14y agoThat's fair. Though I think anyone who just picks technologies based on these bar graphs alone is also missing the point, so some critical thinking is required to interpret these benchmarks, as usual.
- coldtea 14y ago>This is a perf benchmark, not a comparison of how concise your code can be (...) performance concerns become important, even if you have to write ugly code That goes against the notion of benchmarking. It's about measuring as well as you can how idiomatic code will perform.