Thanks! This looks great. I will definitely retest myself. I'm under some deadlines at the moment with my $dayjob so I might not be able to evaluate it until next Friday.
Darren > On Feb 8, 2014, at 7:27 AM, Lukas Eder <[email protected]> wrote: > > Hi Darren, > > This is now fixed on GitHub master for jOOQ 3.3: > https://github.com/jOOQ/jOOQ/commit/c3d5f4d819736ce3c9f4bcc3a7cc4645dd94a5ba > > I have added a new Setting to activate / deactivate this cache. The flag > defaults to true in jOOQ 3.3.x and will default to false when merged onto > jOOQ 3.2.4. > By adding such a cache, I have observed tremendous performance improvements > both when using "mapping by jOOQ's naming conventions" (A) and "mapping by > annotations" (B). For 200'000 runs of Result.into(Class) with four Records: > > A: From 7.3 seconds to 0.9 seconds > B: From 134 seconds to 1.4 seconds (!) > > The latter is what you have observed yourself and can be verified > impressively on these Oracle Java Mission Control screenshots: > > Before: > > <image.png> > > After: > > <image.png> > > As can be seen, the actual work from the map() method now makes up most of > the CPU effort. > > It would be awesome, of course, if you could verify these results at your > side if you have time next week. > > Cheers > Lukas > > 2014-01-29 16:47 GMT+01:00 Lukas Eder <[email protected]>: >> Hi Darren, >> >> 2014-01-24 Darren Shepherd <[email protected]> >> >>> Yeah, doesn't exactly seem ideal. But at the end of the day, we're >>> not exactly looking for RecordMapper caching, but instead caching of >>> reflection information. >> >> The reason I mentioned this is because RecordMapper already does its own >> reflection information caching. But that doesn't help, of course, if >> RecordMapper is not reused very often. >> >>> Would it be possible to change the annotation >>> utils methods, such as getAnnotatedMembers(), to accept a >>> Configuration object as an argument, then do something like the >>> following: >>> >>> static final List<java.lang.reflect.Field> >>> getAnnotatedMembers(Configuration configuration, Class<?> type, String >>> name) { >>> if ( configuration instanceof SomeMagicalInterface ) { >>> ((SomeMagicalInterface)configuration).getCachedStuff(type, >>> name); >>> } >>> ... >>> } >>> >>> If we are focusing on just providing caching for reflection, it may >>> make sense to not specifically tie the interface and logic to the >>> record mapper. In fact you could just use Configuration.data(...) as >>> your cache. >> >> That's not a bad idea at all. jOOQ currently puts all sorts of "local" flags >> with the "org.jooq.xxx" namespace in various copies of that map, mostly for >> the lifecycle of an ExecuteListener. But having a cache for arbitrary things >> in there is likely to work around any class loading issues that might arise >> with a static cache. >> >> So essentially, the cache could globally store { org.jooq.Field, >> java.lang.Class } => { List<java.lang.reflect.Method>, >> List<java.lang.reflect.Field> }, or something similar. Sounds like a plan! >> >> Cheers >> Lukas > > -- > You received this message because you are subscribed to a topic in the Google > Groups "jOOQ User Group" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jooq-user/YpIpRVVsd5A/unsubscribe. > To unsubscribe from this group and all its topics, 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.
