Well, I still have the same opinion about this issue... but would be
really nice to have these same benchmarks run in JDK 1.4 and 1.3 in the
same machine. I'll try to do it later, I'm downloading the sources.
On Thu, 2003-01-09 at 08:39, Oliver Jowett wrote:
> 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
>
> ---------------------------(end of
broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to
majordomo@postgresql.org)
--
Felipe Schnack
Analista de Sistemas
felipes@ritterdosreis.br
Cel.: (51)91287530
Linux Counter #281893
Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341