db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <ti...@espinhas.net>
Subject Re: 10.8.1 testing
Date Wed, 27 Apr 2011 11:38:05 GMT
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!


On Wed, Apr 27, 2011 at 12:43 PM, Knut Anders Hatlen <knut.hatlen@oracle.com
> wrote:

> Myrna van Lunteren <m.v.lunteren@gmail.com> 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 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

View raw message