Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Reference creation in a loop  RSS feed

 
Yuriy Grechukhin
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy ranchers!
I'm still new to this site, so this question might have been asked in the past...
I'm interested if these two codes will be different in performance, and if so by how much


It seems to me that the first one would be slower since we create a new reference on every iteration, instead of changing that reference, but the compiler might optimize it (I usually do the second way).
Any ideas?
[ January 21, 2004: Message edited by: Yuriy Grechukhin ]
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24215
37
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No difference at all. They compile to virtually the same bytecodes. You can check this with "javap -c" if you'd like. The only difference is that since the order of declaration of the two variables "i" and "o" changes, the specific JVM local variables (registers) assigned to then switches.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ernest is correct. That is because the memory for local variables is typically allocated on the stack frame at the start of a method and freed at the end. There really is no creation or deletion going on in your loop.
 
Yuriy Grechukhin
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ilja Preuss:
That is because the memory for local variables is typically allocated on the stack frame at the start of a method and freed at the end.

Aha! That's what was throwing me off. I though for every iteration a new reference would be created on the stack, then at the end, the stack ptr would move up (or down depending on how you look at it).
Now I wonder how the performance might suffer if something like this would be implemented through recursion (just for fun).
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Yuriy Grechukhin:

Now I wonder how the performance might suffer if something like this would be implemented through recursion (just for fun).

What to implementations do you have in mind?
 
Yuriy Grechukhin
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm, well, let's say something like this:

This actually gave me a StackOverflowException when I added 10000 elements
But I'm wondering about performance... The last line of output (time) was 370ms (the fastest of 10 runs I did on my system).
Here's the code that is without recursion:

Amazingly it seems SLOWER . The last line of output (time) was 400ms (the fastest of 10 runs I did on my system).
 
Yuriy Grechukhin
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, now the times are the other way around: 361 w/o recursion, 371 with recursion... So I guess the times might the same...
They might or they might not,
You never can tell with bees.
-- Winnie-the-Pooh
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!