Temporary Object Instances

General Discussion
1

Does JME operate a temporary object instance pool?

Its a scheme where objects such as Vector3f and ColorRGBA etc are requested from the pool and once finished with are put back into the pool. This in effect saves creating a new object every time.

Some objects maybe more expensive to create than others but the consensus is that it is cheaper to fetch an unused object from the pool and put it back than to create a new one each time with the garbage collecting and an ever growing garbage bag considered.

I had a look at the code and it isn’t integrated into the objects so there might be a manager somewhere. I really appreciate your help and comments.

Regards

2

Yeah, TempVars. But note that on proper VMs, when you create and release an object in a “stack situation” (like in C) its basically free to allocate and release it. On Android its worse though.

3

Notes here
→ new is actually way cheaper than malloc, as each thread has a few mb for internal managment sync less, while malloc in pure version request memory from the os.

→ GC in modern jvm (aka no android) is mostly parralized, so as long as you have one cpu not used by the game it is barely noticeable.

Using a ES all of my data is immutable, so i create several hundredths objects per gametick, all without any issue.

At least if you go multithreading your pool approach will become problematic anyway, as then you either need to sync it, or keep one for each running thread. So keep in mind tempvars is only for rendere thread

4

In my project, although setting the parameters is done from a multithreading environment it is the render thread which performs the object update to ensure all changes are synchronized to a frame.

The calculation objects are only created if a modification is detected so it isnt necessarily overhead heavy.

Still, my conscience says it is preferable to use a temp pool that to create and garbage everytime. However, if as you say, Empire_Phoenix, there may be little advantage given the considerations you state.

Regards

5

Would the following be typical/correct usage, thanks…

public void update(float _tfp)
 {
 TempVars tv=TempVars.get();

ColorRGBA c=tv.color;

c.set(parent.color);
c.mult(this.color);
c.mult(overrideColor);

material.setColor(c);

tv.release();
}
6

yes excactly.
Though, note that there is a limit on how much tempVar instances you can get (afaik it’s 5 of them). Meaning you can’t stack TempVars calls like that more than 5 times

TempVar v1 = TempVars.get();
.....
         TempVar v2 = TempVars.get();
..... and so on
.....
v2.release
v1.release

And since the engine uses them extensively, there might be situations where you can hit the limit faster.
So as a rule of thumbs we don’t really recommend to use them for your game.

However, you can easily duplicate the pattern and have your own tempVar system for your game.

7

But in that usage it must be ensured, that the setColor actually copies the value and not use the reference right?

8

yes you’re right.
And mat.setColor(“Param”, c) actually use the instance. So @Penny you have to clone it there.

9

Thank you very much for this knowledge.

Seeing as the engine uses TempVars extensively I do not wish to interfere with its operation. I have decided to develop my own system of object pooling and I will probably use a synchronised concurrent linked list. I am sure I have an old implementation kicking around somewhere.

Many Thanks

10

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentLinkedQueue.html

It is really not possible to write a more efficient and correct thread-safe queue in Java. Worth considering if it fits your needs.

Though in your example there was no real reason to use a pool at all… you could have another field effectiveColor that you store your results into. Then you don’t even need to reset it to the material every time as it will be picked up automatically after the first set.

There is a reason that there aren’t many object pools kicking around in the JME community… mostly there are better ways to do things in a lot of cases.

11

Yes that is exactly what I have used in the past.

It is my thinking that for say, a million computations (for plucking a value out of the sky), it is preferable to use an object pool instead of retaining a million instances or creating a new one and garbaging it each time.

The results of my performance tests, which were conducted a quite a few years ago, I might add, resulted in that ConcurrentLinkedQueue is in fact a lot cheaper than creating new instances of even quite simple objects and the memory overhead is significantly less too.

I agree that my example on the surface looks as if it doesn’t need this kind of management but I am planning for scalability where there could be the possibility of countless instances.

Regards

12

Yes, but in your example, you already have an instance that you MUST keep around… the one that you set into the Material parameter. You might as well keep a reference to it so that you don’t duplicate it with object pool storage, don’t have to fetch it form an object pool, and don’t have to reset the parameter every frame.

9/10 times there are similar solutions for other object pool use-cases… where an object pool is actually LESS optimal than alternatives. Once you’ve eliminated all of those then you can see if a pool is worth it.