Declaring local variables inside loop

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Hi,

I do some looping like this:

FunctionInputTuple tupleWithSecond;
while (tupleStates.contains(first)) {
tupleWithSecond = FunctionInputTuple.getInstance(
tuple.getSymbol(), tupleStates);
// do some computation, replace ?first? in the list
equivalent &= equivalence.equivalent(firstValue,
secondValue);
}

Now my question is: does it matter that I declare tupleWithSecond
outside the loop? I have the impression that if I leave the first line
out and instead add ?FunctionInputTuple? before the third line, that a
new pointer space is created on the stack for each loop. Or is the
compiler smart enough to see this and optimise it away?

TIA, H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/FEKe+7xMGD3itQRApCNAJ0XAuO9EDzcPLMU+drVSb+7GWuRlwCeMLlI
8DO6B188P50x4WNYLLIx5MQ=
=PA5B
-----END PGP SIGNATURE-----

 

[tom fredriksen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Hi,

I do some looping like this:

FunctionInputTuple tupleWithSecond;
while (tupleStates.contains(first)) {
tupleWithSecond = FunctionInputTuple.getInstance(
tuple.getSymbol(), tupleStates);
// do some computation, replace ?first? in the list
equivalent &= equivalence.equivalent(firstValue,
secondValue);
}

I have a question out of curiosity, since I have seen some of your other
posts. Are you perhaps thinking a bit too much of lists and Lisp/Scheme.
I am just curious as you are clearly demonstrating that chain of thought
in your comments and examples. My point is that it might be in the way
of utilising (or perhaps understanding) java correctly. i.e. writing
code that follows java idioms instead if Lisp, essentially using the
wrong language for how you think.

Just a thought though.

/tom

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

tom fredriksen schreef:

I have a question out of curiosity, since I have seen some of your other
posts. Are you perhaps thinking a bit too much of lists and Lisp/Scheme.
I am just curious as you are clearly demonstrating that chain of thought
in your comments and examples. My point is that it might be in the way
of utilising (or perhaps understanding) java correctly. i.e. writing
code that follows java idioms instead if Lisp, essentially using the
wrong language for how you think.

I do have some interest in Lisp, but I have never used it. Thing is,
part of what I am programming now (tree automata and manipulations
thereof) has been programmed before in Lisp, and I look at that code
from time to time to get some inspiration. So I might be contaminated
there. But I only do Java (until now). Just from time to time, I see
some useful constructs there, and would want to use them in Java too...

The question about lists could just as well be stated as a comparison
with Perl lists. This question is about coding style and performance, I
don?t see a link to Lisp here. In Lisp, this would probably involve
mapcars and stuff. If you want to enlighten me on the Java idiom of a
loop like the above, please feel free to do so.

Just a thought though.

You could have mailed this to me privately. Unfortunately, you
e-mailaddress does not work, so I have to clutter the NG with this.

H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/F78e+7xMGD3itQRArTNAJ9EBLlgoTxFEQKNvB58VSgydQhbbwCfSTob
u6cieZl734xDl1bE12crQSU=
=t6mM
-----END PGP SIGNATURE-----

 

[Robert Klemme]

In general you should limit the scope of names, so
declaring the variable inside the loop is preferable.

I don't know the technical details and the two cases
*may* in principle differ performance wise (I don't
think they do), but this whould be what is commonly
known as "premature optimization" and should be avoided
anyway.

Seconding that: the JVM is very likely to optimize this situation. I
definitively would prefer to limit the scope as much as possible to avoid
errors from accidetally reusing the same value and enabling proper data flow
analysis of the compiler.

Kind regards

robert

 

[Jacob]

I do some looping like this:

FunctionInputTuple tupleWithSecond;
while (tupleStates.contains(first)) {
tupleWithSecond = FunctionInputTuple.getInstance(
tuple.getSymbol(), tupleStates);
// do some computation, replace ?first? in the list
equivalent &= equivalence.equivalent(firstValue,
secondValue);
}

Now my question is: does it matter that I declare tupleWithSecond
outside the loop? I have the impression that if I leave the first line
out and instead add ?FunctionInputTuple? before the third line, that a
new pointer space is created on the stack for each loop. Or is the
compiler smart enough to see this and optimise it away?

In general you should limit the scope of names, so
declaring the variable inside the loop is preferable.

I don't know the technical details and the two cases
*may* in principle differ performance wise (I don't
think they do), but this whould be what is commonly
known as "premature optimization" and should be avoided
anyway.

 

[Chris Uppal]

Now my question is: does it matter that I declare tupleWithSecond
outside the loop?

Doesn't make any difference from an efficiency point-of-view (with some minor
caveats). The same bytecode is emitted whether you declare the variable inside
the loop or outside. There are, of course, good software engineering reasons
for declaring the variable in the most restricted scope possible.

-- chris

 

[opalpa]

I echo the "limit scope" advice other folks have voiced. If the code
is optimized by compiler then great, no performance hit and a logical
improvement. If the code is not optimized by compiler the performance
hit is likely negligable and possibly less than the expected amount of
time/money a bug would waste.

I think it wise to write logically correct code, simple code. Run it,
test it. If there are performance complaints think of them as a
modification of service level agreeement. In this way you are not
optimizing, but meeting requirements.

There is a quote in Jon Bently's book on optimization that comes to
mind, it goes like:

Two Rules of Optimization:

Rule #1: Don't optimize.
Rule #2: [For experts only] Don't optimize yet.

If we seperatly consider experts and non-experts:
For non-experts: don't optimize means that at no point in time they
should optimize.
For experts: Still don't optimize, but you can contemplate
possibilities. If there ends up being a performance reason for
modifing source you'll have some plans, but you did not do it yet.
When the performance reason comes you'll be meeting requirements and
the fact that you are optimizing will be secondary.

This is part of how I view optimizing. The other main part of my
optimization thinking is regression tests. That is: the slow, simple,
correct version of code stays and is used to verify results from any
attempted sped up versions.

All the best,
Opalinski
(e-mail address removed)
http://www.geocities.com/opalpaweb/

 

[Ed]

Hendrik Maryns skrev:

Now my question is: does it matter that I declare tupleWithSecond
outside the loop?

Slightly curious (and ignorant of compiler optimisations), I ran the
following code a few times with the appropriate lines tweaked.

Over 10 million iterations, the difference between declaring inside and
outside the loop was 0.7%. That's worth the benefits of variable-scope
minimising.

..ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.



class Loop {
private class Test {
private int index = 0;
Test() {
}
void execute() {
for (int i = 0; i < 100; i++) {
index++;
}
}
}
public static void main(String[] args) {
new Loop().execute();
}
void execute() {
long startTime = System.currentTimeMillis();
// Test test = null;
for (int i = 0; i < 10000000; i++) {
Test test = new Test();
test.execute();
}
System.out.println("Time elapsed: " + (System.currentTimeMillis() -
startTime));
}
}

 

[Adam Maass]

I do some looping like this:

FunctionInputTuple tupleWithSecond;
while (tupleStates.contains(first)) {
tupleWithSecond = FunctionInputTuple.getInstance(
tuple.getSymbol(), tupleStates);
// do some computation, replace ?first? in the list
equivalent &= equivalence.equivalent(firstValue,
secondValue);
}

Now my question is: does it matter that I declare tupleWithSecond
outside the loop? I have the impression that if I leave the first line
out and instead add ?FunctionInputTuple? before the third line, that a
new pointer space is created on the stack for each loop. Or is the
compiler smart enough to see this and optimise it away?

I use, as a general rule:

declare local variables at first use.


Enough space for all local variables in a method are allocated on the stack
frame when the method starts, regardless of their source scope. So where you
declare a local variable doesn't (usually) matter to performance. There are
a couple of caveats here: if you declare variables inside, say, loops, and
you do this more than once in a method, odds are that the slots allocated to
those variables will be re-used. Likewise, local variables are not
de-allocated until the /method/ terminates, not the block that they are
declared in. That means that a local variable that holds a reference to an
object will prevent that object from being garbage collected until method
termination -- even if that variable goes out of scope earlier.

-- Adam Maass

 

[Chris Uppal]

Slightly curious (and ignorant of compiler optimisations), I ran the
following code a few times with the appropriate lines tweaked.

Over 10 million iterations, the difference between declaring inside and
outside the loop was 0.7%. That's worth the benefits of variable-scope
minimising.

This was obviously nonsense, so I ran it myself. And I get exactly[*] the same
result ! Declaring 'test' inside the loop make it run ~7% slower than with it
outside.

([*] I'm assuming you dropped a decimal point somewhere.)

(That was using a 1.5.0 client VM. I modified the code to run execute()
repeatedly so as to allow time for the JITer to do its stuff. I also checked
that the inner loops weren't being optimised away.)

Looking at the bytecodes the only difference between the two (besides the
explicit assignment of null which is outside the loop and therefore irrelevant)
is that the stack slots used for variables "test" and "i" are interchanged (if
'test' is declared outside, then it gets stack slot 3 and 'i' uses slot 4,
otherwise 'test' uses 4 and 'i' uses 3). There are /no/ other differences.

Considering that the loop in execute() is actually quite long (what with object
creation, initialisation, and the nested loop) I find it quite surprising that
such a small change has any detectable effect. Shocking, in fact.

Live and learn...

-- chris

 

[Larry Barowski]

Slightly curious (and ignorant of compiler optimisations), I ran the
following code a few times with the appropriate lines tweaked.

Over 10 million iterations, the difference between declaring inside and
outside the loop was 0.7%. That's worth the benefits of variable-scope
minimising.

This was obviously nonsense, so I ran it myself. And I get exactly[*] the
same
result ! Declaring 'test' inside the loop make it run ~7% slower than
with it
outside.

On my system, running under Java 1.5.0_06, the one with
'test' declared inside the loop runs about .7% faster, fairly
consistently (on a second call to new Loop().execute()).

 

[Robert Klemme]

Live and learn...

With the attached test I get

server vm
50000000 iterations
Rehearsal
Outer: 1015ms
Local: 953ms
0.9389162561576355 local/outer
Test
Outer: 969ms
Local: 938ms
0.9680082559339526 local/outer

client vm
50000000 iterations
Rehearsal
Outer: 953ms
Local: 922ms
0.9674711437565582 local/outer
Test
Outer: 922ms
Local: 922ms
1.0 local/outer

On Windows Java 1.4.2_06

On all tests the worst case that the "local" variant was 1.7% slower than
the "outer" in server mode.

robert

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Chris Uppal schreef:

Doesn't make any difference from an efficiency point-of-view (with some minor
caveats). The same bytecode is emitted whether you declare the variable inside
the loop or outside. There are, of course, good software engineering reasons
for declaring the variable in the most restricted scope possible.

That?s the answer I sought (and hoped) for, now I can assuredly follow
the smallest scope advises, which I, of course, heartily agree with.

Thanks all, H.

--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/aSie+7xMGD3itQRAkpPAJ9GpsHg2wUYSHCpdj8rEiswVJTNsQCffAQh
yLUAhl2Fs5V8BpH+cf8uKQA=
=9Rv9
-----END PGP SIGNATURE-----

 

[Chris Uppal]

This was obviously nonsense, so I ran it myself. And I get exactly[*]
the same
result ! Declaring 'test' inside the loop make it run ~7% slower than
with it
outside.

On my system, running under Java 1.5.0_06, the one with
'test' declared inside the loop runs about .7% faster, fairly
consistently (on a second call to new Loop().execute()).

Odd. On mine, running 1.5.0 (ie. first release) looping explicitly so that the
GC load stabilises and the JIT is warmed up, I repeatably get that declaring
the 'test' variable inside the loop slows it down by 7.5%.

Here's the raw numbers. Tthe lines starting with 'W' are warmup runs which are
not included in the average. The first column is the 'inner' time, the second
is the 'outer':

W: 4977 4757
W: 5027 4687
W: 5127 4677
0: 5057 4747
1: 5057 4667
2: 5127 4677
3: 5037 4777
4: 5027 4677
5: 5037 4767
6: 5047 4667
7: 5138 4666
8: 5048 4756
9: 5038 4686
10: 5108 4696
11: 5028 4767
12: 5047 4666
13: 5138 4667
14: 5047 4767
15: 5037 4677
16: 5077 4727
17: 5037 4677
18: 5127 4677
19: 5037 4767
Inner mean: 5064
Outer mean: 4708

And I'll append the code.

-- chris

============================
class Loop
{
static final int WARMUP = 3; // sufficient by experiment
static final int LOOPS = 20;

private class Test
{
private int index = 0;

void execute()
{
for (int i = 0; i < 100; i++)
index++;
}
}

public static void
main(String[] args)
{
Loop loop = new Loop();
long totalInner = 0;
long totalOuter = 0;
long inner = 0;
long outer = 0;
for (int i = 0; i < WARMUP; i++)
{
inner = loop.executeInner();
totalInner += inner;
outer = loop.executeOuter();
totalOuter += outer;
System.out.println("W:\t" + inner + "\t" + outer);
}
totalInner = totalOuter = 0;
for (int i = 0; i < LOOPS; i++)
{
inner = loop.executeInner();
totalInner += inner;
outer = loop.executeOuter();
totalOuter += outer;
System.out.println(i + ":\t" + inner + "\t" + outer);
}
System.out.println("Inner mean: " + totalInner / LOOPS);
System.out.println("Outer mean: " + totalOuter / LOOPS);
}

long
executeInner()
{
long start = System.currentTimeMillis();

for (int i = 0; i < 10000000; i++)
{
Test test = new Test();
test.execute();
}

return System.currentTimeMillis() - start;
}

long
executeOuter()
{
long start = System.currentTimeMillis();

Test test = null;
for (int i = 0; i < 10000000; i++)
{
test = new Test();
test.execute();
}

return System.currentTimeMillis() - start;
}
}
============================

 

[Hendrik Maryns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message

Chris Uppal schreef:

This was obviously nonsense, so I ran it myself. And I get exactly[*]
the same
result ! Declaring 'test' inside the loop make it run ~7% slower than
with it
outside.

On my system, running under Java 1.5.0_06, the one with
'test' declared inside the loop runs about .7% faster, fairly
consistently (on a second call to new Loop().execute()).

Odd. On mine, running 1.5.0 (ie. first release) looping explicitly so that the
GC load stabilises and the JIT is warmed up, I repeatably get that declaring
the 'test' variable inside the loop slows it down by 7.5%.

Here's the raw numbers. Tthe lines starting with 'W' are warmup runs which are
not included in the average. The first column is the 'inner' time, the second
is the 'outer':

W: 4977 4757
W: 5027 4687
W: 5127 4677
0: 5057 4747
1: 5057 4667
2: 5127 4677
3: 5037 4777
4: 5027 4677
5: 5037 4767
6: 5047 4667
7: 5138 4666
8: 5048 4756
9: 5038 4686
10: 5108 4696
11: 5028 4767
12: 5047 4666
13: 5138 4667
14: 5047 4767
15: 5037 4677
16: 5077 4727
17: 5037 4677
18: 5127 4677
19: 5037 4767
Inner mean: 5064
Outer mean: 4708

Interestingly, on a 64-bit machine, but with a 32-bit JVM, I get the
following. Anyone care to explain?

W: 2598 2515
W: 2449 2447
W: 2446 2446
0: 2448 2447
1: 2446 2447
2: 2448 2446
3: 2447 2446
4: 2448 2447
5: 2446 2448
6: 2447 2446
7: 2436 2433
8: 2433 2429
9: 2430 2431
10: 2439 2435
11: 2435 2434
12: 2432 2430
13: 2429 2430
14: 2436 2438
15: 2436 2435
16: 2430 2434
17: 2429 2430
18: 2435 2438
19: 2435 2435
Inner mean: 2438
Outer mean: 2437

And then, using a 64-bit JVM:

W: 299 281
W: 228 211
W: 208 193
0: 184 180
1: 187 180
2: 195 180
3: 183 180
4: 185 180
5: 185 182
6: 181 183
7: 182 182
8: 181 182
9: 183 182
10: 184 183
11: 184 180
12: 185 180
13: 189 180
14: 185 182
15: 183 188
16: 183 182
17: 182 183
18: 182 185
19: 181 182
Inner mean: 184
Outer mean: 181

Oops! Quite a bit faster, I guess I?ll use that one from now on!

Ah, I wish I could afford a computer like this one myself...

I guess the difference just gets negligible because this machine is so fast.

So I added a variable

static final int TEST_LOOPS = 10000;

And changed this little piece of code:

private class Test
{
private int index = 0;

void execute()
{
for (int i = 0; i < TEST_LOOPS; i++)
index++;
}
}

To get the following result (with the 64-bit jvm):

W: 6551 6497
W: 6551 6553
W: 6583 6437
0: 6525 6456
1: 6533 6470
2: 6536 6472
3: 6609 6429
4: 7046 6559
5: 6695 6553
6: 6833 6767
7: 6512 6423
8: 6500 6420
9: 6521 6787
10: 6490 6409
11: 6488 6324
12: 6499 6331
13: 6498 6465
14: 6488 6309
15: 6496 6546
16: 6505 6410
17: 6518 6436
18: 6635 6448
19: 6499 6523
Inner mean: 6571
Outer mean: 6476

So indeed this confirms you results, though, as can be seen, not
consistently from run to run. This might be a bit biased, as I did do
other things in the background while running the test.

Even more: with TEST_LOOPS = 10, I get the following, which seems to be
due to the creation of the objects, as the 10 loops can barely be
significant (notice the small difference to 100 loops):

inner outer
W: 255 258
W: 214 208
W: 211 211
0: 211 205
1: 202 189
2: 187 171
3: 173 161
4: 163 171
5: 166 156
6: 162 183
7: 198 196
8: 191 178
9: 181 163
10: 162 153
11: 159 155
12: 158 153
13: 158 155
14: 157 157
15: 158 154
16: 158 154
17: 154 158
18: 156 158
19: 154 158
Inner mean: 170
Outer mean: 166


Cheers, H.
--
Hendrik Maryns

==================
www.lieverleven.be
http://aouw.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/bGue+7xMGD3itQRAia/AJkBX0Ez/3x7zcPey2EwVyosCyZTsACfdPSP
evfWJ0aJZwhBo14VSvOr9po=
=ftbT
-----END PGP SIGNATURE-----

 

[Chris Uppal]

Odd. On mine, running 1.5.0 (ie. first release) looping explicitly so
that the GC load stabilises and the JIT is warmed up, I repeatably get
that declaring the 'test' variable inside the loop slows it down by 7.5%.

A few other datapoints:

I tried the same code under 1.4.2_b28 on the same machine. The difference is
~4%.

I tried it under 1.5.0_5 on a different machine. The difference is ~3%.

Given that, and the figures that Larry posted, it seems to be a quirk of how
the generated code interacts with the specific machine.

What I still can't get over is how /big/ the effect is -- remember that we are
not in the inner loop.

I don't plan to change my coding style, though ;-)

-- chris

 

[Chris Uppal]

Interestingly, on a 64-bit machine, but with a 32-bit JVM, I get the
following. Anyone care to explain?
[...]
Inner mean: 2438
Outer mean: 2437

And then, using a 64-bit JVM:
[...]
Inner mean: 184
Outer mean: 181

Oops! Quite a bit faster, I guess I?ll use that one from now on!

That sounds as if it might be the 64-bit JMV running automatically in -server
configuration (which seems to optimise most, but not all, of the test away[*]).
Try giving it an explicit -client flag.

[*] At least it does on my machines under both 1.4 and 1.5. But not,
apparently, on whatever machine Robert's using, even though that is a Windows
box like mine. Very odd...)

-- chris

 

[Robert Klemme]

Interestingly, on a 64-bit machine, but with a 32-bit JVM, I get the
following. Anyone care to explain?
[...]
Inner mean: 2438
Outer mean: 2437

And then, using a 64-bit JVM:
[...]
Inner mean: 184
Outer mean: 181

Oops! Quite a bit faster, I guess I?ll use that one from now on!

That sounds as if it might be the 64-bit JMV running automatically in
-server configuration (which seems to optimise most, but not all, of
the test away[*]). Try giving it an explicit -client flag.

[*] At least it does on my machines under both 1.4 and 1.5. But not,
apparently, on whatever machine Robert's using, even though that is a
Windows box like mine. Very odd...)

Win 2k Server, P4 1.8GHz, 2GB main mem.

I changed the test and also increased mem with -Xmx1024m -Xms1024m

-server

100000000 iterations
Rehearsal
Outer: 1437ms
Local: 1453ms
1.011134307585247 local/outer
Outer: 1391ms
Local: 1390ms
0.9992810927390366 local/outer

1.0053041018387554 local/outer
Test
Outer: 1297ms
Local: 1282ms
0.9884348496530455 local/outer
Outer: 1296ms
Local: 1282ms
0.9891975308641975 local/outer
Outer: 1297ms
Local: 1391ms
1.0724749421742483 local/outer
Outer: 1297ms
Local: 1265ms
0.9753276792598303 local/outer
Outer: 1297ms
Local: 1281ms
0.9876638396299152 local/outer
Outer: 1282ms
Local: 1343ms
1.047581903276131 local/outer
Outer: 1313ms
Local: 1297ms
0.9878141660319878 local/outer
Outer: 1282ms
Local: 1281ms
0.999219968798752 local/outer
Outer: 1281ms
Local: 1297ms
1.0124902419984387 local/outer
Outer: 1297ms
Local: 1281ms
0.9876638396299152 local/outer

1.0047144292449184 local/outer


-client

100000000 iterations
Rehearsal
Outer: 1469ms
Local: 1391ms
0.9469026548672567 local/outer
Outer: 1390ms
Local: 1375ms
0.9892086330935251 local/outer

0.9674711437565582 local/outer
Test
Outer: 1375ms
Local: 1359ms
0.9883636363636363 local/outer
Outer: 1375ms
Local: 1391ms
1.0116363636363637 local/outer
Outer: 1422ms
Local: 1390ms
0.9774964838255977 local/outer
Outer: 1391ms
Local: 1391ms
1.0 local/outer
Outer: 1407ms
Local: 1515ms
1.0767590618336886 local/outer
Outer: 1438ms
Local: 1437ms
0.9993045897079277 local/outer
Outer: 1375ms
Local: 1375ms
1.0 local/outer
Outer: 1344ms
Local: 1391ms
1.0349702380952381 local/outer
Outer: 1375ms
Local: 1359ms
0.9883636363636363 local/outer
Outer: 1375ms
Local: 1359ms
0.9883636363636363 local/outer

1.006485551632197 local/outer

I guess differences may be due to GC kicking in, clock inaccuracy or such.
IMHO they seem neglectible.

robert

 

[Chris Uppal]

I repeatably get
that declaring the 'test' variable inside the loop slows it down by 7.5%.

I'm sorry to be continually following myself up, but here's another datum:

I tried changing:

long start = System.currentTimeMillis();

to:

long x = System.currentTimeMillis();
long start = System.currentTimeMillis();

in both executeInner() and executeOuter(). The variable 'x' is not otherwise
referenced, but does not seem to be optimised away. That exactly reversed the
difference between the two methods. I now suspect that it's to do with what
positions variables end up at in the physical RAM used for the stack. Whether
its an alignment effect, or some oddity of caching I don't know and don't plan
to find out ;-)

-- chris

 

[Chris Uppal]

I guess differences may be due to GC kicking in, clock inaccuracy or such.
IMHO they seem neglectible.

Do you mean the differences in overall speed between -client and -server ? If
so then they are certainly /much/ smaller than the order-of-magnitude
differences I see for my test. (using 1.5 GHz, WinXP sp1, jdk 1.4.2 or 1.5.0)

I presume it's something to do with the different structures of our test code
in terms of what loops are in what methods, and which methods get called /in/
loops.

-- chris