[DaGuy]

I'm not very deep in regards to the inner workings of the JVM. Can anyome comment if there's a perfomance hit when declaring an object reference outside a loop versus inside one. For example see Sniplet A versus Sniplet B below. This is all so I can save a single line of code!!



Not quite. It's actually aims to improve my understanding more than to satisfy any anal retentive tendencies.


// --- Sniplet A -----------------

String s;
for ( int i=0; i<LoopLimit; i++ ){
s = A.MethodThatReturnsString();
}



// --- Sniplet B -----------------

for ( int i=0; i<LoopLimit; i++ ){
String s = A.MethodThatReturnsString();;
}



Thanks!

[Chuckit]

Well, you can just compile two different versions of a method and time them..

[depolitic]

My hunch is that the second for loop will be marginally faster. Reason: As soon as initialize the String s; in the first for loop the String s is initialized to null automatically.

Then once inside the for loop it is re initialize to A.MethodThatReturnsString(). You have thus performed two initializations.

In the second for loop you initialize the String s only only once to the value of A.MethodThatReturnsString().

Also the second for loop would be better practice as it is recommended that as soon as you declare a data type it should be initialized, that way you never have data types with a nonsense value.

This is only my hunch, as I to am still learning Java.

[DaGuy]

It's really hard to say which is the best approach... I'll run some test and report on my results.

[javabeans]

I think both ways will probably perform similarly. I remember reading somewhere that in modern JVM (1.3+) Strings are treated in a way that if you declare two variables that has the same value, in memory its actually points to the same memory address space. The reason is that Strings are immutable.

[DaGuy]

Ok, I ran some tests. The details are included below. It turns out that Sniplet B is faster but only after a large number of iterations. My conclusion is that for most typical applications there is no noticible performance hit.

RESULTS:

For loop = 10
sniplet A is equall to sniplet B.

For loop = 100
sniplet A is slower than sniplet B, 8 out of 10 times. Max difference = 1 milliseconds


For loop = 1000
sniplet A is slower than sniplet B, 9 out of 10 times. Max difference = 2 milliseconds

For loop = 100000
sniplet A is slower than sniplet B, 10 out of 10 times. Max difference = 12 milliseconds

For loop = 1000000
sniplet A is slower than sniplet B, 10 out of 10 times. Max difference = 26 milliseconds

[Arkham_c]

The main reason to declare the variable outside the loop is that you can wrap the assignment in a try/catch. So:

Code:
String s;

try
{
    s = A.MethodThatReturnsString();
}
catch (Exception e)
   // do something here
}

// do something with 's' here

If you don't do this, and the inside of thetry might not execute, you'll get a compilation error.

[DaGuy]

I never encountered any problems with a try-catch in this sense. In any event, my insecurity took the best of me... I was 99% sure of that but still went back to the code to eliminate that 1% of doubt.

I introduced the try-catch blocks into my experiment and both sniplets compile and run as expected. So there, you got me buddy...

[Gametes]

In snippet B, why don't you get an "already declared" type error? I thought you always had to declare the variable outside of a loop because otherwise you get overlapping variable names.
I could've sworn I've gotten this error in Obj-C before, but ok.

[DaGuy]

There are definite differences in both approaches (further evidence provided by my little test). I don't know why the compiler doesn't throw an error. I guess it all depends on how the compiler handles references or how it optimizes them. I turned on verbose compilation and no warnings are thrown either.

I don't know if this helps:

String S = A.MethodThatReturnsString();

The left hand side of the assigmnet operator says that "S" is memory location that can point to a string (who said that Java didn't have pointers?) and the right hand side actually provides the memory location of a String object.

Any comments?

[javabeans]

Originally posted by Gametes:
In snippet B, why don't you get an "already declared" type error? I thought you always had to declare the variable outside of a loop because otherwise you get overlapping variable names.
I could've sworn I've gotten this error in Obj-C before, but ok.

You don't because variable s is declared in side the for loop, which is the scope of that variable. You can access/reference s within the { } of the for loop without any compilation error.

[itai195]

This may just be my C-cronyism rearing its ugly head, but I think code is much more maintainable when you have all your declarations in one place. Hence, declaring a variable inside a loop just seems ugly to me, and makes me want to cry

That said, I don't think you will see any compilation errors as a result of doing things this way. What you may see, assuming you're writing a large program, are bugs rearing their heads later, and then you'll wonder where this String S came from. Even that's not so bad since Java gives you nice stack traces... ahh, the bad habits

[ameat]

Originally posted by itai195:
This may just be my C-cronyism rearing its ugly head, but I think code is much more maintainable when you have all your declarations in one place. Hence, declaring a variable inside a loop just seems ugly to me, and makes me want to cry

...yeah, but you've got to admit it's nice being able to declare your for loop counter...

Code:
for (int i = 0; i < stuff; i++) { ... }

...inside the loop as opposed to the top of the program. that always annoyed me about c.

[itai195]

Originally posted by ameat:
...yeah, but you've got to admit it's nice being able to declare your for loop counter...

Code:
for (int i = 0; i < stuff; i++) { ... }

...inside the loop as opposed to the top of the program. that always annoyed me about c.

Oh yes, very true. Very true...

[bousozoku]

In either case, you're passing back a new String, because Strings are immutable, which has quite a bit of overhead. When you use the named String reference over and over, the old String is marked for garbage collection and the new one's reference is given to the named reference.

If you're in a situation where you need String data which changes frequently, use a StringBuffer.

[DaGuy]

Thanks. I used String as an example since they are fairly well-understood. My goal was really to get some discussion in regards to the merit of having the reference outside or inside the loop -for any object, not just string. I was curious to see if there were any significant performance hits.