From: | Oliver Jowett <oliver(at)opencloud(dot)com> |
---|---|
To: | Felipe Schnack <felipes(at)ritterdosreis(dot)br> |
Cc: | Michael Paesold <mpaesold(at)gmx(dot)at>, pgsql-jdbc <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: synchronized code |
Date: | 2003-01-09 10:39:13 |
Message-ID: | 20030109103909.GA22133@opencloud.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
On Thu, Jan 09, 2003 at 10:40:33AM +1300, Oliver Jowett wrote:
> Actual numbers to follow when I'm done.
The detailed data (and source) is now at:
http://www.randomly.org/misc/java-allocation-pooling-benchmark.txt
Summary:
With no lock contention:
Client VM: allocation is about twice as fast as synchronizing.
Server VM: allocation is about 5% slower than synchronizing.
With lock contention, synchronizing is dramatically slower than allocation
using either VM type; this effect is worse when multiple CPUs are used.
There's very little difference between allocating a new buffer each time,
or reusing an buffer via setLength(0), ignoring synchronization. In some
cases (e.g. 2 cpus with spare capacity) allocating a new object is faster!
There's another effect in here somewhere that's generating some noise.
(compare "no synchronization" to "synchronized buffer" for one thread --
sometimes the synchronized version is faster, but they're doing the same
operations other than synchronization so I'd expect it to be always
slower). Reviewing the code, this may be due to a different cost in
accessing locals vs. instance fields. If so this will also affect
the synchronization vs. allocation case.
... but enough benchmarking for one day I think!
-O
From | Date | Subject | |
---|---|---|---|
Next Message | Felipe Schnack | 2003-01-09 10:57:43 | Re: synchronized code |
Previous Message | Neil Conway | 2003-01-09 03:02:15 | Re: 7.3 Prepared statements |