Hi Adam,
> I have posted this comment last Sunday but it looks like it went astray -
> here is the repost.
Yes, google groups took it for spam... I'm sorry for that
> I have been watching jOOQ for a while and have to say that you are doing a
> fantastic job!
> (...have you got a day time job as well?)
Thank you. Yes, I do ;-)
> During these tests I have first noticed that it takes disproportionally long
> time to construct the Factory class.
> To give you an example I have a test case that inserts 12 records for 7
> different entity types (in other words
> 12 records into 7 tables). The whole test runs 266 ms and out of this 140 ms
> is spent to construct the Factory
Hmm, that is quite surprising, indeed. I hadn't measured such an
overhead so far, when using Yourkit profiler. I was under the
impression that constructing a simple object in Java wouldn't take
that much time. The Factory constructor hardly has any overhead. But
as you've mentioned further down, hashCode() is indeed a problem.
> All in all one could say that this is not a big deal as you construct the
> factory once (and incur this cost only once) but
> since the Factory is constructed with the requested dialect it seems a bit
> pointless to have this done for all available dialects.
These "default instances" are indeed a relict from earlier jOOQ days
and have been removed in jOOQ 3.0
> [...]
> Which eventually leads to adding key/value pairs to a linked hash map that
> calls hashCode() on TableFiedlImp class
> that is implemented in the AbstractQueryPart class:
>
> @Override
> public int hashCode() {
> // This is a working default implementation. It should be overridden
> by
> // concrete subclasses, to improve performance
> return create().renderInlined(this).hashCode();
> }
Yes, this hashCode implementation is quite suboptimal. There is a
pending issue addressing this:
https://github.com/jOOQ/jOOQ/issues/1626
> The bottom line is that the constructor is called for each column of each
> record that is constructed.
> (see the attached snapshot for the whole stack trace). I have not profiled
> any updates as yet but it
> seems likely that the behaviour will be the same as they most likely reuse
> the same functionality.
Some of these things are going to be improved in jOOQ 3.0. But it's a
good thing to remind me of profiling jOOQ again some time. I'll keep
this as a reminder:
https://github.com/jOOQ/jOOQ/issues/1936
> PS
> It is a great shame that there is not a simple JUnit profiler add-on
> available which would show these
> kinds of issue straight away - any takers?.
Yes, well, Yourkit does a good job, usually...
