3 ms·

Those are fairly uselss synthetic benchmarks. How many apps do you have in production that are purely key value stores with a random access profile? And if yo

• tethis 13y ago
  The point of these benchmarks is that, given the same database and the same queries, languages have different performance profiles. If I build an application in Java and Python, with the same database backend, running the exact same set of SQL queries, the Java application should perform better.
  • BugBrother 13y ago
    The point is that with a db which hits the disk, the different execution times will generally look like rounding errors.
    • tethis 13y ago
      If you look at those benchmarks, for the same db queries on the same db backend, throughput and latency can differ by an order of magnitude. We're talking the difference between 200 or 2000 requests per second, or 50ms vs 500ms latency. That's not a rounding error.
      • BugBrother 13y ago
        My (and others') point is this obvious thumbs rule: If you hit the disk, that I/O will dominate the latencies. Even while using a scripting language. E.g. a DB that fits in RAM is different, of course. It is hence easy to create benchmarks that generates every possible result. So is your comment relevant to my point? Is there something about that benchmark which contradict the previous thumbs rule? (And yes... With lots of calculations, scripting languages aren't a good idea either in many cases. Also obvious.)