Making a new list with new objects every single frame

Hey guys. :slight_smile:

I’m working on a game for android that requires some processing of the data model, before it can be rendered correctly.
It’s not much, but it requires me to assemble a new List every frame, with some list elements in it (between 4 and 500).
The element objects are very small convinience-things like the Vector3f, employing only 2 integers, and 2 floats.
The list assembly is essentially copying a similar list’ (the raw model) important values, and doing some minor tweaking with some of the values. The minor tweaking is virtually nothing, in terms of CPU usage.

I’m afraid of the list assembly though. I have not been able to test my game on android yet, as I’m waiting for a new workstation to arrive, but the game runs smoothly on PC.

I have the following questions about performance in this situation.
Is it better to not reinitialize my list every frame, and just clear it?
Would I be far better off using an object pool for these small short-life objects?
Is there a chance the garbage collector in android is actually capable of cleaning this up, without showing lag?
Should I not worry about it, and get on with my game?

I’m quite new to the platform, so I don’t know how well I have to manage object creation and garbage collection. I know that I can slack off quite a lot in this respect on the PC.
In the past, I have drawn the model directly so I never really had this problem. It could very well be that this exercise of making a few new objects to use for rendering is common practice, and I’m just stressing over something that hasn’t been a problem in Java for a long time. Reading about memory fragmentation, and garbage collector lag makes me nervous, but it could be that those issues only are with huge datamodels, and not applicable in this case. Anyway, please clue me in!

Thanks for reading, and perhaps responding. Cheers!

If its more likely to be 4-30 I’d say it doesn’t matter. If you expect 400-500 quite often, then I’d personally recommend an object pool.

However with that said.
“Should I not worry about it, and get on with my game?” <-- this, until its an issue

I wouldn’t bother pre-optimizing it at all. Why not just write it and if it works fine, move on. Only come back to this when its an issue?

It’s for the length snake. 500 is possible, but really not something that would happen often. The assembly takes place only once every frame.

Alrighty then. I guess I’ll throw in an FPS counter and take it from there. Assuming a pool is reasonably easy to implement at a later stage. Thanks!

EDIT: Even though this question is closed now, I’d still love to hear from you if using a Pool for these kind of things is something everybody does, and how bad exactly it is to rely on the garbage collector. Many different views and practices on this would be awesome. Has this ever affected any of your games a lot? Is it bad on android specifically?

I know this is a dead thread, but anyway.
Avoid doing new on android. Always use an object pool. Code is not complicated. Here is mine, that works well for mainly all cases :


class Bucket<T>
{
	private final ArrayListEx<T>	elements	= new ArrayListEx<T> ();
	private int						usedCount;
	private final Class<T>			classOfT;

	Bucket(Class<T> classOfT)
	{
		this.classOfT = classOfT;
	}

	Bucket(Class<T> classOfT, int initialCapacity)
	{
		this ( classOfT );
		reserve ( initialCapacity );
	}

	final void reserve(int capacity)
	{
		for (int i = 0; i < capacity; i++)
			elements.add ( newT () );
	}

	final int capacity()
	{
		return elements.size ();
	}

	final int size()
	{
		return usedCount;
	}

	final T get(int index)
	{
		return elements.get ( index );
	}

	final T add()
	{
		if (usedCount == elements.size ())
			elements.add ( newT () );

		final T obj = elements.get ( usedCount );
		usedCount++;

		return obj;
	}

	final int remove(int index)
	{
		elements.swap ( usedCount - 1, index );
		usedCount--;
		return index - 1;
	}

	final int remove(T obj)
	{
		final int index = elements.indexOf ( obj );
		return remove ( index );
	}

	final void remove(ArrayList<T> list)
	{
		final int count = list.size ();
		for (int i = 0; i < count; i++)
			remove ( list.get ( i ) );
	}

	final void clear()
	{
		usedCount = 0;
	}

	private final T newT()
	{
		try
		{
			return classOfT.newInstance ();
		}
		catch (Exception e)
		{
			return null;
		}
	}
}

Example of use :


Bucket<Firework> sprites = new Bucket<Firework>(Firework.class);
...
Firework f = sprites.add();
f.setPosition(...); // reset all you need cause we are using recycled instances
f.setColor(...);
f.setVelocity(...);
...

I’m using here a ArrayListEx instead of a ArrayList, it is just the same class with some additionnal methods that you will rewrite (I can only see the swap method here).

Using a pool is really performance friendly for a very little cost and almost no drawback (except maybe the quick ‘swap with last’ method I’m using for removal, that changes order, which sometime is important).

Cheers.