• Advertisement

Archived

This topic is now archived and is closed to further replies.

[java] Variables and performance

This topic is 4969 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m a bit curious how to do with variables. If I have a method that will be called very often, say the render method. This method wants some temporary variables. Some variables will be used very much per method call and some just once or twice. Is there any recommendation of how to do here? Should I avoid local variables in a much used method and put them at a class level(to avoid the recreation of variables so the gc won''t panic), or will that slow things down? I''m sure you understand what I mean. I''d appreciate any input on when (if at all) to not use local variables, or if the best thing is to always use local variables (copy class member and parameter variables to local variables). Performance wise and/or memory wise.

Share this post


Link to post
Share on other sites
Advertisement
Use local variables in general, they can be created on the stack and can remain in the cache, they are easier to debug and they don't bloat/clutter your class definition.

But bottom line: don't try to optimize until the very end.

Regards,
Jeff

Edit: Sorry, didn't even notice this was the Java forum! Hopefully most my comments still apply.


[ CodeDread ]

[edited by - rypyr on June 9, 2004 1:35:38 PM]

Share this post


Link to post
Share on other sites
I second rypyr in that you shouldn''t try to optimize until the end. For the most part, anyway.

Honestly, it''s up to you. It depends on what your variables are that you wish to make either class or local variables. If you''re talking primitives (i.e., int, float, double, etc.), then chances are it won''t make a whole lot of difference to have them local vs. class. It doesn''t take a whole lot to allocate space for these, after all.

On the other hand, if your variables in question are of a class that you designed, then it *may* be good to make them class variables. However, there are only very specific circumstances in which this is a good idea. Keep in mind that the more things you make class variables, the less and less encapsulation is going on. True, if you''re careful with your code, that''s ok, but most of the time it''s best to keep with safe programming practices.

Just for clarification, could you tell us what it is that you''re trying to do? That is, what are these temporary variables and what are they for?

Share this post


Link to post
Share on other sites
How big will your variables be? If you're just talking about a few temporary variables used in calculations, keep them local. That's faster since you benefit from locality of reference. If on the other hand you require something like an array of 1000 objects and you're allocating a new one every time you call the method, it would be better to make that array global if possible. In general, don't worry about memory unless you're getting an out of memory error. Also, profile your program (java -Xrunhprof:help); this can show you both memory usage and time issues; you might be surprised at what's really slowing you down.

[edited by - Matei on June 9, 2004 9:31:44 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don''t agree with the opinions above.
The problem with local variables and java is the garbage collector! memory or whatever else is not a problem. If it run and has a lot of variable to check/remove you''ll likely to see it, in fact you see your application slow down once in a while.
Let''s take an example, for a render you use 10 local variables. ok 10 variables is not too much, but since it''ll be done at each render you''ll likely to have (10*60) variables each second if your game runns at 60fps, if the gc runs every 5 seconds it''ll have to check/remove 3000 variables!

By the way i never heard of rypyr''s cache stuff (in java).

Share this post


Link to post
Share on other sites
Yeah, but local variables are created on the stack and not on the heap.
Is garbage collection even relevant for that?

shmoove

Share this post


Link to post
Share on other sites
shmoove is correct. As long as you don''t use the "new" operator variables will be created on the stack. The GC will never have to clean up after them.

Matei and Strife both use excellent examples (imho).

A good explanation of JVM operation is available at JavaWorld.
http://www.javaworld.com/javaworld/jw-06-1996/jw-06-vm_p.html

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
quote:
Original post by Anonymous Poster
I don''t agree with the opinions above.
The problem with local variables and java is the garbage collector! memory or whatever else is not a problem. If it run and has a lot of variable to check/remove you''ll likely to see it, in fact you see your application slow down once in a while.
Let''s take an example, for a render you use 10 local variables. ok 10 variables is not too much, but since it''ll be done at each render you''ll likely to have (10*60) variables each second if your game runns at 60fps, if the gc runs every 5 seconds it''ll have to check/remove 3000 variables!

By the way i never heard of rypyr''s cache stuff (in java).


GC doesn''t even come into play...

And even if it did, don''t worry about it. The whole point of a GC is so you don''t have to concern yourself with memory management. If , when the game is being profiled, the GC is a problem, then work on it.

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
quote:
Original post by Anonymous Poster
I don''t agree with the opinions above.
The problem with local variables and java is the garbage collector! memory or whatever else is not a problem. If it run and has a lot of variable to check/remove you''ll likely to see it, in fact you see your application slow down once in a while.
Let''s take an example, for a render you use 10 local variables. ok 10 variables is not too much, but since it''ll be done at each render you''ll likely to have (10*60) variables each second if your game runns at 60fps, if the gc runs every 5 seconds it''ll have to check/remove 3000 variables!

By the way i never heard of rypyr''s cache stuff (in java).


GC doesn''t even come into play...

And even if it did, don''t worry about it. The whole point of a GC is so you don''t have to concern yourself with memory management. If , when the game is being profiled, the GC is a problem, then work on it.


The point of GC is not to remove the concern one should have about memory management, but rather to reduce its cost on project developement.

In general (to fresco) I think you may have picked up that creating lots of "new" objects in a often called method will more then likely eat up a lot of time and memory which the system will eventually need to reaquire... and thus just as your game is running it will suddenly slow way down to do this (that is the general point.)

Keep in mind that Objects and Arrays are created with new each in the heap, while references to those Objects can be kept on the stack and can be used via (automatic stack variables to use a C term.) And if accessed often are likely to remin in cache.

Also, I believe what rypyr was referring to was indeed machine memory cache either level 1 or 2 in this case; however, since the JVM is a ''Virtual Machine'' there is no reason that it too wouldn''t implement some kind of cache memory model.



" ''No one has control -- control is just a fantasy. And being human is difficult.'' "

Share this post


Link to post
Share on other sites
I was talking about primitive vars, int, float, etc.

I would have said objects otherwise

But I might as well finish what I''m doing the good safe way and then profile some. I did think everything went on the heap and thus making the gc work quite a lot, but that does not seem to be the case then, that''s good.

Thanks for the answers though, I find it hard sometimes to get to know the inner workings of java. Thanks TheClair for the link.

Share this post


Link to post
Share on other sites

  • Advertisement