Comparing Querydsl, jOOQ, JEQUEL, activejdbc, iciql and other query DSLs
Can someone point me to some resources about the performance comparison among the different Query DSL libraries available for using with Java, like: Querydsl, jOOQ, JEQUEL, activejdbc, iciql and etc...
Background: I m using Spring JDBC template, but that still required the queries to be written in plain string format. Although I don't have issues in writing the direct queries, but I m concerned having direct dependency on DB table names. I don't want to use any ORM framework like Hibernate or JPA/EclipseLink. I need the raw performance as high as possible (IMO, they are good for more CRUD centric applications). I can afford some slight overhead for the these DSLs only if that is a little (I believe, it'll be mostly StringBuilder/String concatenations!)
I've considered using named queries externalised in some xml. But just trying to evaluate the value different Query DSL libraries provide.
Edit: more on my requirement: I want to know the performance comparison among these when building a moderately complex query using their API methods. All I need is to generate a query string using any of these query DSL libraries and pass that to Spring JDBC template. So, I want to know if addition of this intermediate step incurs considerable performance penalty, I want to use named queries or build my own library which just uses StingBuilder or similar approach
update my experience with jOOQ, iciql, QueryDSL:
All though I missed to mention this in my original post, I m also keen about the ease of use & the overhead I need to have in my entity classes (like if any additional annotations or implementations required).
jOOQ:
- requires changing the entity properties to the library specific way
- can return SQL query string
Iciql:
- entity can be mapped with no or little changes (can be mapped using total 3 ways)
- but with that it limits to only select queries (for update/delete/... requires entity changes again)
QueryDSL:
- multiple ways to bind entities with table (other than library specific ways, using JPA annotations is supported). but we need to modify the entities at least
- no simple/direct way to get the query string
(all observations are with little knowledge I've on these; if any of these are incorrect, please correct)
With all of the above, I m sticking with writing named queries :( But as the Lukas Eder answer seems explains about my original post concern (performance), I've accepted his.
Answer
In modern JVM's you shouldn't be worrying about SQL string concatenation too much. The true overhead any database abstraction layer may produce (compared to the relatively high round-trip time to the database and back), is usually due to second-level caching, which is done in Hibernate/JPA. Or by inefficiently mapping object models to SQL in a way that using indexes or general query transformation becomes impossible.
Compared to that, string concatenation is really negligible, even for complex SQL constructs with several UNIONs, nested SELECTs, JOINs, semi-JOINs, anti-JOINs, etc, so I'm guessing all of the frameworks you mentioned perform in a similar manner, as they allow you to keep control over your SQL.
On the other hand, some frameworks or usage modes in those frameworks may actually fetch the whole result set into memory. That can cause issues if your result sets are large, also because with Java's generics, most primitive types (int, long, etc) are probably mapped to their corresponding wrappers (Integer, Long).
As for jOOQ (of which I'm the developer), I have previously profiled the library with YourKit Profiler for massive query execution. The bulk work was always done in the database, not in query construction. jOOQ uses a single StringBuilder for every query. I imagine (not verified), that QueryDSL and JEQUEL do the same...
As for iciql, which is a fork of JaQu, there might be some additional impact by the fact that they use Java instrumentation to decompile their natural syntax. But I guess that can be omitted, if it means too much impact.