FWIW, for this test I did not do ANY POJO mapping. For the JOOQ with Record
version I just did #fetch(r->{return Test(r.value1(), r.value2(),
r.value3()});
On Thursday, January 8, 2015 at 4:03:27 PM UTC-8, Robert DiFalco wrote:
>
> 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.
>
> About 120ms is extra overhead for Result vs. ResultSet and about 130ms is
> parsing the actually query from the fluent interface. The time includes
> getting a pooled connection, committing, and closing it.
>
> I'll try to put it into an isolated benchmark when I get a chance, right
> now the benchmark is intermixed into my server with a lot of proprietary
> stuff in it.
>
>
> On Thursday, January 8, 2015 at 11:12:49 AM UTC-8, Robert DiFalco wrote:
>>
>> Thanks for the information! I have some type questions but I'll tack them
>> onto the other thread.
>>
>> I haven't profiled it, I probably should. It was just a general concern
>> that built after seeing the number conversions and just in generally being
>> more familiar with the ins and outs of result sets -- I knew what I was
>> dealing with implementation-wise there. I know what the PostgreSQL driver
>> does with result sets and I was having some trouble stepping through the
>> JOOQ result processing code with a debugger (there's a lot of code). But
>> I'm more familiar with it now.
>>
>> And FWIW, my first thought is always that (a) there is a reason for each
>> thing JOOQ does that evolved over time and (b) with a feature rich library
>> I am taking the wrong approach based on not understand the feature set yet
>> in a holistic manner. Then I work from there. :)
>>
>>
>> On Thursday, January 8, 2015 at 10:47:17 AM UTC-8, Lukas Eder wrote:
>>>
>>>
>>>
>>> 2015-01-08 18:41 GMT+01:00 Robert DiFalco <[email protected]>:
>>>
>>>> I'm reposting part of this from an email thread. I have a complex
>>>> dynamic query where I ultimately map from a ResultSet instead of using
>>>> Record. Lukas was curious why I was using ResultSet instead of Record to
>>>> create my beans. Here's my reply:
>>>>
>>>> Thanks Lukas, on Record vs. RecordSet this is probably because I am not
>>>> familiar with all of JOOQ, especially on the Converter classes. I did TRY
>>>> Record but here were my issues:
>>>>
>>>> 1. Using your Record class creates several temporary objects per-field
>>>> on every row. In particular two ConvertAll converters.
>>>>
>>>
>>> That's true, but they go out of scope almost immediately, so they are
>>> GC'ed very quickly. Have you profiled this area and found a significant
>>> issue or is this more of a general concern?
>>>
>>>
>>>> These seemed unnecessary for me since I could just optimally call
>>>> #getLong or #getString, etc. on the ResultSet without extra overhead.
>>>>
>>>
>>> *Some* data type conversion still needs to be done when you call
>>> ResultSet.getLong() or ResultSet.getString(). Especially in the
>>> ResultSet.getLong() case, as you're unboxing a Long, and then perhaps
>>> boxing it again.
>>>
>>>
>>>> 2. The ConvertAll implementation is not super efficient for Numbers.
>>>> For example, I use INT in my database, but my Object model uses Long so
>>>> that if I change the implementation I will not impact clients. To convert
>>>> from Integer to Long you first get the row value as an Integer from the
>>>> ResultSet. Then you perform a #toString on it, then you convert it to a
>>>> BigInteger, then finally get the Long value. I'd suggest adding a case to
>>>> ConvertAll something like this:
>>>>
>>>> if (Number.class.isAssignableFrom(fromClass) {
>>>> return (U)((Number)from).longValue();
>>>> }
>>>>
>>>> You might want to think about this for all the number to number
>>>> conversions.
>>>>
>>>
>>> You're absolutely right. The current implementation is just the fallback
>>> for random types that are not a Number. I have registered an issue for this:
>>> https://github.com/jOOQ/jOOQ/issues/3909
>>>
>>>
>>>> I thought about creating a synthetic Record for this query that I could
>>>> create dynamically (to match the dynamic nature of the query), then I
>>>> could
>>>> control the field names, types, and bindings. There is probably a better
>>>> way to do it but I'm still exploring.
>>>>
>>>
>>> You could probably do that, but beware of our understanding of
>>> "backwards-compatibility":
>>>
>>> http://www.jooq.org/doc/latest/manual/getting-started/semantic-versioning/
>>>
>>> We might be adding new methods to the org.jooq.Record type between minor
>>> releases
>>>
>>> 3. One other reason, but not too important if they were equally
>>>> efficient, is that it was easier to write my lambda to rs.getLong(pos)
>>>> instead of record.getValue(pos, Long.class).
>>>>
>>>> Is there a simple inline way to specify converters as fields are added
>>>> to a result set in such a way that they are used when results are read?
>>>>
>>>
>>> Yes, if you're using code generation, then you can register Converters
>>> (or Bindings, or both) directly with your Fields:
>>> http://www.jooq.org/doc/latest/manual/code-generation/custom-data-types/
>>>
>>>
>>>> Or do I have to do it globally in Configuration? Basically, I would
>>>> like NOT to have to specify a Type to record#getValue, since if the type
>>>> is
>>>> right in the field, it should be in Record correctly.
>>>>
>>>
>>> That's already the case. The <T> type information that you provide with
>>> your SELECT statement is going to be the type that is materialised in the
>>> Result / Record for that type.
>>>
>>>
>>>> The double ConvertAll instantiation from record#getValue(int,Class<?>)
>>>> to #convert0 seems a bit much.
>>>>
>>>
>>> I'll further explaine in the other discussion that you've started. In
>>> short: After 6 years of existence and almost 4000 issues on GitHub, there
>>> are reasons for most of these things :) (although there is also legacy, and
>>> a couple of bugs, such as the above inefficient Number conversion)
>>>
>>> Thanks for being so responsive and open to my opinions!
>>>
>>>
>>> Well, thank YOU for taking the time to writing them down! I will soon
>>> blog about the value of the "fresh user" to a community that has already
>>> gotten used to many of the quirks of a platform. Every friction that a
>>> fresh user reports is a friction to be taken very seriously.
>>>
>>> Cheers
>>> Lukas
>>>
>>
--
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.
