views:

157

answers:

5

I'm working on an application with a 3D viewport which refreshes 30 times a second (or at least tries to render that fast). Unfortunately, the code is complicated enough that simply converting it to test for the performance effect would take quite a while, but the two conditions I'd be comparing are as follows:

ObjectToRender p = objectsToRender.get(i);
p.render();

as opposed to:

objectsToRender.get(i).render();

I'm sure this sounds like a severe case of micro-optimization but, as noted above, this code is constantly being called and has zero outside factors to influence its performance (Disk I/O, Network, etc).

+7  A: 

I would expect these two pieces of code to JIT compile to exactly the same machine code, assuming that you don't use "p" anywhere after this fragment.

Darron
Compile a sample and use `javap -c` on it to get my vote. :)
Michael Myers
@mmyers, even if the two don't compile to the same bytecode, his point may still be valid.
Kevin Bourrillion
What he said. Some testing I did recently suggests that the Java JIT is really aggressive compared to say the CLR. You really don't need to worry about obvious micro-optimizations like this one.
Seun Osewa
This was my original thinking as Java seems to be very good about this... Now that performance levels are at about 1/5 of the target numbers, however, I'm less willing to just bypass it without at least asking others ;)
sbook
A: 

The change you suggest shouldn't mattern, although you might get an improvement from moving from indexed-based list access (which is what I assume you're using with "get(i)") to array access.

Steve B.
+1  A: 

Most modern compilers are smart enough to generate a very optimized byte code. I doubt the above 2 calls should make any difference. In fact, they prolly will generate the same byte code.

Mihir Mathuria
A: 

The objectsToRender.get(i) part of your code might be optimised by using an iterator to loop over all the objects to render:

iterator.next().render();

or, if the list of objects is stable, convert it to an ObjectToRender[] once and index directly:

objectsToRender[i].render();
rsp
-1 You offer no proof that either of these is better; nor even can you, since you don't know what environment, version of the JDK, etc. he's running under.Trying to just give a common-sense answer to the question asked doesn't really help this guy.
Kevin Bourrillion
@Kevin, as you already say; giving a proof is not the goal of answers to questions like this, trying to offer advice is. It is up to the OP to see what advice he follows up. That said, for the collection classes that contain a `.get(int)` using an iterator when looping over all objects in the collection is a very good bet for optimising a global algorithm.
rsp
@rsp, I appreciate any and all suggestions, thank you. Thinking from a logical level, just using a toArray() would likely hamper performance as it would need to happen on each viewport refresh.
sbook
I should've come back earlier to finish this off, but after looking over the code we were able to determine that Vectors weren't really required. Switched to ArrayList and used its iterator.. really made a huge difference!
sbook
+2  A: 

There shouldn't be a difference, but I've seen performance differences where I didn't think I should see one.

As you said though, it seems like a micro-optimization and you might get more of a bang by looking for much larger optimizations such as code restructuring or even going to a different graphics toolkit.

If you care about frame rate, you should be displaying or logging your frame rate and have some standardized target for a given pre-programmed test. Once you've done this, testing minor changes should give you immediate feedback regarding various tweaks.

Don't make "Performance Enhancements" without the ability to measure them. It's like you are lost and are suggesting increasing your driving speed to 40 mph over the speed limit because you don't have time to stop and ask for directions.

Bill K
Excellent comparison with the being lost and suggesting increased driving speeds.. I'll have to remember that one! Framerates are displayed in real-time and written to log files, so I've got a pretty good idea about which changes help or hurt when I make them. This was simply too large a change to make for what could turn out to be a wild goose chase..
sbook