Ok, this is a very small thing, but as i often need ray and collisionresults in controllers i used to add them in the attribute of controller. In this way, i don’t recreate ray and collisionresults every frame. However, i still create them as “temporary variables”, and, for this reason, i think that it would be better to have these thing in a tempvars. I am maybe wrong however.
It’s not a big improvement (at all) but it’s also not hard to do and harmless for the stability of the sdk.
Ok, maybe that create a topic for that is an overkill, and maybe i am spamming the forum for nothing ^^.
I think it’s dangerous and usually unnecessary for users to use TempVars at all. You have the ability to keep state. The lower level framework code does not.
And for CollisionResults there is no point since you cannot possibly avoid creating garbage. One more pointer is not going to matter.
About the tempvars, i know that it’s a dangerous thing, but we can easily add some code to detect a leak (just check that all the tempvars are back) at the end of the application - and so be able to detect it while coding.
If i have thousands of object that perform ray tests but sequentially, i don’t need to have thousands of ray and collisionresults - i just need one, or one per thread if i use multithreading. This is the point of TempVars i think.
The idea that some attributes are just here as temporary variable is so real that even in java you have a keyword “transient” to mark an attribute as “garbage”.
And there is an easy way to avoid all the leak with tempvars
[java]
void aMethod()
{
TempVars vars = TempVars.get();
theRealMethod(vars);
vars.release();
}
[/java]
In this way, you can do whatever you want in the “theRealMethod” method (except release the vars ), including returns in the middle of the code, and the vars will still be release after.
Transient marks a field as non-persistable. Which is quite a bit different than “temporary”.
You cannot just check at the end of application because strange errors would have cropped up oddly long before then… and potentially end up hiding themselves.
At the application layer, you already have state holding objects… so just hold onto the stuff you need.
CollisionResults is one object with lots of objects inside it. Every time you cast a ray you are creating many many objects per collision… keeping the single CollisionResult wrapper is kind of a waste of time if you are just trying to avoid GC.
In your sample code, you already have a HUGE BUG. Which is why it’s so dangerous. If you don’t wrap your code in a try/finally then you risk leaking if an exception happens even if the outer code catches it and moves on. Now your application will be in an odd state.
This is why I say it’s bad for applications to use TempVars. It’s an ugly and dangerous thing that the engine must do to run efficiently on Android. You should store your state in your own objects. The code that uses TempVars does not have that option.
Also, try/finally would get you out of creating a dangerous method just to avoid managing the tempvars… which is in itself dangerous because now you have a method that separately must remember not to do anything like release them, etc… Just a really really bad idiom.
), including returns in the middle of the code, and the vars will still be release after.