Hi Ryan, Thanks for reporting these things. I had thought about similar improvements to the Record.into(Class) algorithm. Indeed, it's a waste of CPU power, to reflectively discover relevant fields and methods at every call.
Caching mappers might seem an obvious way to solve this if the cache is sophisticated enough. But one (caching) size won't fit all, it wouldn't be easy to implement this sensibly in jOOQ. Another option would be to leverage code generation, as you said. This is already done when generating DAOs with jOOQ. Generated DAOs instanciate a ReflectionMapper instance for reuse. Without using DAOs, it is a bit more difficult to associate mappers with records and POJOs. Note that a 3.1 feature request plans for adding a RecordMapper factory registry to the Configuration, defaulting to the current behaviour: https://github.com/jOOQ/jOOQ/issues/2311 The request's main purpose was to override the default behaviour to handle more complex mapping scenarios, globally. I think that this might be the cleanest way to solve your performance issues...? What would be any specific requirements you might have towards this registry? Cheers Lukas 2013/6/17 Ryan How <[email protected]> > 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]>: >> > 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 jooq-user+...@**googlegroups.com. >> > For more options, visit >> > https://groups.google.com/**groups/opt_out<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. > > > -- 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.
