Hi Sachin, Thank you for your message.
Yes, jOOQ does add some overhead in benchmarks compared to JDBC or "almost JDBC" APIs, like JDBI or sql2o. Benchmarks help us spot issues in "hot loops", and we've fixed many of them in jOOQ 3.7.1: https://groups.google.com/forum/#!topic/jooq-user/cUxmqtvY3Zw More fixes are on the way. The most important overheads (in benchmarks) are caused by: 1. StringBuilder to construct the SQL string (this cannot be avoided in jOOQ, but you can work around this in your client code) 2. Primitive wrapper types (you can work around this by using JDBC directly to execute jOOQ queries) 3. The default of loading the entire result into memory (what everyone does in production), instead of throwing away the data right after fetch (what hardly anyone does outside of benchmarks) Now, let's try to understand benchmarks in the context of real world use: 1. Most people run benchmarks against H2, and then even against H2's in-memory mode. This skips the effects of: a) network latency between client and server b) disk I/O in the database c) other networking effects, like distributed CPU load. The in-memory H2 database runs in the same process like the benchmark, which certainly helps the JIT and GC, etc. 2. Benchmarks are mostly isolated, single-threaded runs. This skips the effects of: a) productive load and OLTP contention on shared resources b) limited resources in caching 3. Benchmarks run only very few distinct queries. This skips the effects of: a) parsing SQL and creating execution plans b) result cache misses (e.g. in H2!) As you can see, a benchmark measures the performance of the benchmarked item in... wait for it... benchmark situations :) These benchmarks are useful for library developers like ourselves, because we do strive to optimise our code as much as possible, even for benchmark-y edge cases. And they allow us to measure the true *overhead* we're creating. But they don't help you as a user assess the effect of the library in your real-world application, because you won't be running the same query one million times (and no other queries). *TL;DR*: The most important issues with jOOQ's overhead can be remedied by caching the SQL strings generated by jOOQ and running the SQL with JDBC directly, if you really need the throughput in one or two services. In most cases, you don't need to worry about this overhead. The added value you're getting from jOOQ will certainly outweigh any performance doubt Final note, we're in production in very large systems in banks, insurance companies, etc. The only time we hear these performance complaints is when competitors benchmark us against their very simple libraries :) See also: http://www.jooq.org/doc/latest/manual/sql-execution/performance-considerations Cheers, Lukas 2016-01-30 1:35 GMT+01:00 sachin walia <[email protected]>: > Hi Lukas, > > I am in process of building a product that may have little high number of > writes on DB. I am using postgresql 9.5 as the database. So far in > development I am using sql2o but it seems like the developer has abandoned > the project as no release or bugfix has happened since last one year. > Moreover having gone through the documentation of jOOQ I really like what > is offered. > > One concern is that the developer of sql2o initially claimed that it is > about 650% faster than jOOQ. I am just wondering if your team has done any > testing of your own to verify such claims. > > https://github.com/aaberg/sql2o > > thanks, > > Sachin Walia > > -- > You received this message because you are subscribed to the Google Groups > "jOOQ User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
