Hello, I did a bit of profiling myself, and I've found a couple of hotspots, which I'm summarising here: https://github.com/jOOQ/jOOQ/issues/3065
There are a couple of places where excessive memory is consumed by not reusing references to certain objects. For example: Avoid wrapping Field[] in a new RowImpl every time a Record is created - https://github.com/jOOQ/jOOQ/issues/3954 Avoid creating unnecessary Iterators and ArrayLists in AbstractStore.getAttachables() - https://github.com/jOOQ/jOOQ/issues/3947 Replace ArrayList<ExecuteListener> by ExecuteListener[] in ExecuteListeners to avoid excessive Iterator creation - https://github.com/jOOQ/jOOQ/issues/3946 AbstractScope creates an excessive amount of HashMaps, internally - https://github.com/jOOQ/jOOQ/issues/3944 Other hotspots include unnecessary processing, such as: Add RenderKeywordStyle.AS_IS - https://github.com/jOOQ/jOOQ/issues/3931 There are more hotspots, which I'll resolve as we go. I believe that outside of a benchmark, the overhead is probably negligible, but I can certainly see that there is an overhead to be noticed in a benchmark. The largest overhead in memory consumption is caused by the fact that all values are wrapped in boxed types, e.g. java.lang.Integer. This will inevitably put some pressure on the GC. The largest overhead in CPU usage is caused by various occasions of accessing Context.data(), a HashMap that is used while rendering SQL, for the different QueryParts to communicate with each other. These features are needed for emulation of complex SQL clauses. There is certainly room for optimisation there as well, but the improvement will not be easy. I'll keep looking for potential improvements. Also, there is some risk of contention in SchemaMapping, which lazy-initialises its own data. As few users default to actually using the SchemaMapping, I'm sure there is potential for bypassing that feature when it is not active. I'll keep you posted on this thread as soon as I discover anything else. Cheers Lukas 2015-01-10 12:33 GMT+01:00 Lukas Eder <[email protected]>: > Hi Robert, > > Mere numbers don't really help assessing where time is lost. While I trust > you have set up your benchmarks as well as possible, there might be a lot > of hidden caveats that lead to significant overheads that would not appear > in production, normally. Things like: > > - Debug logging being turned on > - Tests not being bootstrapped (jOOQ needs to load all schema metadata, > and caches a lot of stuff, just like JPA, of course) > > Ideally, for us to help you and verify your results, it would be great if > you could publish your complete benchmarks in a completely reproducible > way, e.g. on GitHub. > > I'm aware you private-messaged me parts of your benchmark code, but for > the sake of traceability of this discussion, also in the future by other > readers, it would be best if all relevant information would be contained > and available from this Google Groups discussion. > > Cheers, > Lukas > > 2015-01-09 18:01 GMT+01:00 Robert DiFalco <[email protected]>: > >> As you suspected, there was something wrong with my timing code. Here's a >> more formal comparison for a query returning a single record. It is much >> better. I'm not surprised that JPA is faster given that it is using a >> pre-parsed query with @NamedQuery. I'm getting some weird overhead with >> @Transactional and JOOQ that I need to figure out. For what it's worth, >> when the number of records returned is around 250 the difference between >> the two disappears. >> >> JOOQ-NP means no-parse, just sending a query string and processing >> Results. JOOQ-RS does a parse like JOOQ but processes a ResultSet directly >> instead of a JOOQ Result object. >> >> JPA (avg=755.4us, total=3.776s, samples=4998, ops=1323.97) >> JOOQ (avg=824.4us, total=4.121s, samples=4998, ops=1213.11) >> JOOQ-NP (avg=790.1us, total=3.949s, samples=4998, ops=1265.64) >> JOOQ-RS (avg=821.9us, total=4.108s, samples=4998, ops=1216.65) >> -- JPA is 9.14% faster than JOOQ >> -- JOOQ-NP is 4.33% faster than JOOQ >> -- JOOQ-RS is 0.29% faster than JOOQ >> >> >> >> On Thursday, January 8, 2015 at 11:15:13 PM UTC-8, Lukas Eder wrote: >> >>> >>> >>> 2015-01-09 1:03 GMT+01:00 Robert DiFalco <[email protected]>: >>> >>>> I just did a little performance testing. >>>> >>>> FWIW, using Record is about 100ms per query slower than ResultSet. >>>> >>>> But worse yet using DSLContext is about 250ms slower than raw >>>> Connection for a simple joined query. For Hibernate/JPA, using a >>>> NamedNativeQuery is about the same time as using a raw JDBC connection and >>>> about 300ms faster than JOOQ. >>>> >>> >>> For a single query? That would be extremely surprising, or perhaps, >>> specific to a particular API usage that might be out of the ordinary. It >>> would be interesting to see this in action with a sample project... >>> >> -- >> 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.
