Hi Lukas, Just following up on this.
We found that in some over 2/3 of our overall request times were spent in JOOQ. The actual database query time was negligible, the other time was spent on the server rendering complex pages. It wasn't specifically the multiple small queries that were taking lots of time, it was using the fetchInto() in any situation. I'm hoping to change over to JOOQ 3 when we get a chance and I imagine this will improve performance a lot, but like you said wouldn't help the small queries. Sorry, I haven't got the profiler data here. But we already managed to get huge performance increases just by some tweaking of how we are using JOOQ. One thing I can think of, which I'm not sure if you would consider... you could cache the results of the reflection (really it is the whole "parsing" algorithm, which uses reflection) globally for each class, so it re-uses the same generated "algorithm" whenever it sees the same class. Seems a waste to need to "parse" the entire class every time .into is called in it's various forms. Or how about being able to pass a "cache" object into the configuration so the lifecycle of the cache can be controlled by the application. It might not be desirable to cache in all cases, especially for one off things, as the memory would never be freed (or global caching could create classloader issues, etc). And with the whole convenience of JOOQ, it would seem a step backwards to have to generate a recordmapper for every POJO. It would mean a whole lot more maintenance every time a field in a POJO changes (and probably would end up resulting in fields getting missed when database schema is updated, then wondering why sometimes a field is null after it has been fetched from the database). Thanks, Ryan On Friday, 5 April 2013 16:32:05 UTC+8, Lukas Eder wrote: > > Hi Ryan, > > There are lots of performance improvements in recent releases of jOOQ, > including 2.6.3 and 3.0-RC1. They also include some improvements of > mapping records to POJOs, where all reflection data is reused > throughout the complete org.jooq.Result. This won't help if you're > running small queries, of course. > > As a general rule of thumb, jOOQ can never beat plain JDBC. It will > always have a certain overhead. Generally, this can be said: > > 1. By default, jOOQ loads the JDBC ResultSet into memory and closes it > early. This can cause some memory overhead, which can be circumvented > by using fetchLazy() > 2. jOOQ doesn't really support primitve types. It will always load > wrapper types for ints, longs, etc. > 3. Construction and rendering of queries comes with its cost. This has > been greatly improved recently. > 4. Reflection will always impair performance. You know your target > domain model better than jOOQ. Use RecordMappers instead of > Record.into() for tuning. > > Please, do post your findings when you're ready. There's always room > for improement. > > Cheers > Lukas > > 2013/4/5 Ryan How <[email protected] <javascript:>>: > > I'm just doing an investigation into JOOQ performance with lots of small > > queries on an embedded database. I was wondering if anyone else has got > any > > experience on JOOQ overhead in constructing queries and inserting > results > > into "Record" objects or POJOs. > > > > I expect the .into() operation could be quite expensive as it needs to > use > > reflection to work out what to do with the class. And it appears to be > quite > > a complicated algorithm. > > > > Anyway, I'll post some findings. I just wanted to see if anyone else had > any > > experience or data for this use case. > > > > Thanks, Ryan > > > > -- > > 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] <javascript:>. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- 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/groups/opt_out.
