Re: TypeInfoCache - Mailing list pgsql-jdbc
From | Daniel Migowski |
---|---|
Subject | Re: TypeInfoCache |
Date | |
Msg-id | 47827A9D.6000002@ikoffice.de Whole thread Raw |
In response to | Re: TypeInfoCache (Oliver Jowett <oliver@opencloud.com>) |
Responses |
Re: TypeInfoCache
|
List | pgsql-jdbc |
Hello Oliver, I redid the benchmark, now with 10,000,000 iterations and externalized functions. Thank you for your hints on writing good benchmarks. These are the results: getString on text_col took 9015.563444ms getCharacterStream on text_col took 12239.496833ms Factor: 1.3575964396485478 getString on varchar_col took 9047.101624ms getCharacterStream on varchar_col took 12268.299423ms Factor: 1.3560474871261377 A feel a bit ashamed of the different results, now, but nontheless do they still speak what I wanted to say: We have a 35% percent slowdown JUST on the getStream-Method, regardless of a varchar or a text type. This is not much if seen in a real life application where the actual waiting for the data is the real bottleneck. And this is just a small slowdown, if the applicatin does not use getString() on the LONGVARCHAR anyway! So I don't see any problems here. I can understand your concerns, if you are used to applications that store everything in text-fields on the database. But a problem is only if you have such an applicatoin, and forgets about its database fields and uses the metadata to remember what its fields have been, now notices the data is in LONGVARCHARs, and uses the stream-methods. But normally, if you create such a database, you created it just for postgresql anyway, want to stay with postgresql, and have access to the code that accesses the JDBC driver. But this again will only contain getString()-Methods, as it was used to, and so your code does not have any penalty if we apply the patch. Please think about this again. Only the very generic applications need the metadata. And if the fields might contain very large data, it is good if they use the "slow" interface. The 33% will be reduced to max 1% at all anyways if mixed in the other code. Thank you and with best regards, Daniel Migowski Oliver Jowett schrieb: > Daniel Migowski wrote: > >> getString on text_col took 8.27384ms >> getCharacterStream on text_col took 14.26489ms >> Factor: 1.724095462324628 >> getString on varchar_col took 9.57153ms >> getCharacterStream on varchar_col took 12.76733ms >> Factor: 1.3338860140437319 > >> Conclusion: There is no real performance loss even in the worst case >> (which should never occur anyway), so please accept my patch. I wish >> you all a happy new year! > > I'm confused. Don't your numbers show a 30%-70% slowdown when using > getCharacterStream()? > > Also some quick notes about microbenchmarks: > > - 1000 iterations isn't really enough to get useful numbers, try > 20,000+ for JIT effects or considerably more for GC effects > - server vs. client JVM can have quite different behaviours, you > should check both > - put your inner benchmark loops in a separate method as some JIT has > method-level granularity > - benchmark the same code path in your warmup loop as you actually > measure the numbers from. In your code, you're benchmarking a > different code path to the one you run in your warmup loop. > > -O > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
pgsql-jdbc by date: