Hi Knut, How exactly did you notice the performance change with DERBY-5068? I would like to be able to replicate this myself. Was it just during the test runs? Or do you have a concrete scenario where it's noticeable?
I'm very interested in finding the issue on this one and I'm available to put some work into making it better. It's no good having a convenience feature if it's slowing down Derby, I think. @ Rick, I would like to do some platform tests myself (it seems they've not yet been ran on OS X 16.* on a x64 JVM) but unfortunately my CPU time lately is precious for the research I'm doing :-( . Everything else looks good though! Tiago On Wed, Apr 27, 2011 at 12:43 PM, Knut Anders Hatlen <[email protected] > wrote: > Myrna van Lunteren <[email protected]> writes: > > > I don't intend to do any performance tests at this point - is anyone > > else doing any? > > I've been keeping an eye on the nightly performance tests on trunk > (http://home.online.no/~olmsan/derby/perf/) and haven't noticed any big > changes after 10.7. I'd expect the performance of 10.8 to be very close > to trunk, but I've started some of the test clients on the RC just in > case. > > The performance changes I have noticed lately are: > > 1) DERBY-5068 - higher CPU usage on the client after the introduction of > UTF-8 CcsidManager. I'm planning to look into it to see where the extra > CPU is spent. But this happened before 10.7.1.1 and shouldn't be a > blocker for the 10.8 release. > > 2) The full table scans in the nightly test, as well as the TPC-B like > transactions, seem to have been running slightly slower the last two > months (see http://home.online.no/~olmsan/derby/perf/tpcb_1y.html and > http://home.online.no/~olmsan/derby/perf/select_sec_noindex_1y.html). It > may be worth looking into if this is an actual degradation or just > noise. But even if it turns out that it is a real performance > degradation, it appears to be so small that it wouldn't be worth > blocking the release. > > -- > Knut Anders >
