Re:Silly benchmarks on completely untuned server code
by lmilcin on Wednesday March 11, 2020 @09:16AM
(#22545541)
> Dynamic languages are generally require less LOC, which generally equates to faster implementations
That's not what I observed. My understanding is dynamic languages promote people to think more higher level and care less about performance and program structure. While dynamic constructs can be efficient, the freedom they give is often misused by developers to create baroque structures that hurt performance mainly because developers don't know how to use them efficiently.
Re:Silly benchmarks on completely untuned server code
by jchrisa on Tuesday March 10, 2020 @11:41PM
(#22542766)
If you want multi-datacenter consistency, then the best of transaction protocols will still measure latency in terms of the speed of light multiplied by the distance between datacenters.
Re:Silly benchmarks on completely untuned server code
by kiadimoondi on Tuesday March 10, 2020 @10:18PM
(#22542320)
Exactly. And even then, database choice faces some of the same selection criteria. What's better supported, does it have well tested and documented client implementations (or do I have the time to write it myself), what features do I need, what features should I anticipate needing, is the performance good enough for what I plan on doing.
0. Performance isn't everything, especially to a lot of companies where having something at all is more important than just being the fastest
1. Dynamic languages are generally require less LOC, which generally equates to faster implementations
2. Rails, Django, <your favorite dynamic language framework> sure are generally bloated, but being able to drop in a library for nearly anything you need cannot be overlooked. Especially for small-midsize companies, spinning up another app server is generally easier than writing a whole bunch of multi-threaded code.
3. The appserver is generally not the bottleneck, rather, of course, its the database.