Yes, exactly that is the problem. Yeah it was just like three lines of code to move the sqlContext.select to the constructor save it as getSQL in the DAO singleton ctor and then just use resultQuery instead in the actual code. Writing warm-up code was actually more tedious but I'll see if I can do it in a more logical way. These aren't benchmarked unit tests so I'm not using JMH. And I didn't want to have to pre-run queries for every single unit test in this Test class (there is a lot of coverage). It's just some IPC system tests where I had to check out timeouts, waits, errors, and I want to keep the "expect" timeout as short as possible so they will run fast.
Thanks for the input. On Mon, Jun 1, 2015 at 10:01 AM, Lukas Eder <[email protected]> wrote: > > > 2015-06-01 18:37 GMT+02:00 Robert DiFalco <[email protected]>: > >> Thanks, yeah I read that. What I'm doing now seems to work pretty well. I >> just save the #getSQL and then when I use I do a >> sqlContext.resultQuery(sql, [values,...]); >> >> Are you thinking (a) this isn't a good idea or (b) that I am not saving >> any cycles? The main reason I'm doing it is that I have several unit tests >> that (unfortunately) require some timing to check timeouts and such. The >> first few will usually fail because the first time I construct the query >> its spends a bit of time creating that query. So whichever test ran first >> would fail. Extracting the string as above seemed to fix the warm-up issue. >> > > Aha, I see. Well, the first query that uses generated meta data will > suffer from the initialisation overhead for all the metadata. Unless you're > doing some magic tricks with classloaders, jOOQ's metadata blocks the > classloader completely in order to be fully class-loaded and intialised in > one go. If that's bothering you in your tests, you might want to bootstrap > 1-2 queries in your tests' @BeforeClass methods. > > An even cleaner solution would be to bootstrap each individual test before > doing the benchmarks. I suspect that JMH provides tools for such > bootstrapping, in case you're using JMH > > I wouldn't proceed with storing the SQL strings for all of your > application, because you probably won't save too many cycles, but you might > have a bit of overhead in your work. Also, as with any cache, you'll risk > regressions because of stale caches - i.e. there might be a case where you > pre-generate SQL that isn't really static. > > Of course, if you feel more at ease this way, and you've already done the > work, that'll be fine, too. > > -- > 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/7jqbm98_Ga8/unsubscribe. > To unsubscribe from this group and all its topics, 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.
