Skip to content
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
161 changes: 161 additions & 0 deletions Utils/ObjectPool.cs
Original file line number Diff line number Diff line change
@@ -0,0 +1,161 @@
using System;
using System.Collections.Generic;
using UnityEngine;

namespace DUCK.Pooling
{
public abstract class PoolableComponent : MonoBehaviour
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct me if i'm wrong, but the API here requires you to subclass this component in order to be poolable. If this is so can I suggest a slight API modification; make this one non abstract and we can just add this to our object if we want to pool it, otherwise I can see a lot of subclassing this just to add it, or unnecessary inheritance. Composition could be our friend here.

I also see opportunity to add a function here to return the object to the pool (destroy it without destroying it), that way we don't need access to the pool from within the object that is pooled. We can just go GetComponent<PoolableComponnet>().ReturnToPool()

If it's non abstract I'd probably think about renaming it. Soime suggestions PoolableBehaviour, PooledItem, PooledElement

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK - done

{
protected internal virtual void OnAddedToPool()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure we need internal here, duck will currently always exist in the project's AssemblyCSharp assembly

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

{
enabled = false;
gameObject.SetActive(false);
}

protected internal virtual void OnRemovedFromPool()
{
gameObject.SetActive(true);
enabled = true;
}

protected internal abstract void CopyFrom(PoolableComponent instance);
}

public static class ObjectPool
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments documenting how the pool works, when it should be used and any pitfalls would be good.

Part of those comments might be a some a warning against blind or excessive usage of a pool which could cause (assumption alert!) slow down of the GC or creating a large memory footprint and all the usual issues with premature optimisation.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to keep this relatively lightweight, so the pools aren't even created until you call ObjectPool.Instantiate - this will create and maintain a pool for the objects to return to when soft-destroyed via ObjectPool.Destroy, but is otherwise transparently identical to the standard Instantiate and Destroy functions, in that they're called as fallbacks if there isn't a pool to use.

I will, though, add guards to prevent a pooled object being pooled a second time, and to prevent the pool from returning destroyed objects, since it's still possible to hard-Destroy something while it's in the pool.

{
private abstract class AbstractPool
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given theres no implementation, this may as well just be an interface,

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True - done

{
public abstract Type ObjectType { get; }

public abstract void Add(PoolableComponent obj);
}

private class Pool<T> : AbstractPool
where T : PoolableComponent
{
private Queue<T> pooledObjects = new Queue<T>();

public override Type ObjectType
{
get
{
return typeof(T);
}
}

public T Remove()
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps Get would be a better name, as it sounds less destructive, theoretically this is where you would (without pooling) be creating the object, not removing it. Removal is just part of the pooling mechanism.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed

{
var obj = (pooledObjects.Count > 0)
? pooledObjects.Dequeue()
: null;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth considering letting the pool manage object creation as well since it handles the other end of the lifecycle and would be much more convenient for the end user.

Its not unusual for pools to return a new instance of the object where you have null if you think that would be less intuitive then a GetOrCreate() method would work.

Copy link
Copy Markdown
Contributor Author

@DSDubit DSDubit Mar 21, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does - ObjectPool is a private class so this will never be called by the end user. See the static Instantiate functions which are for external use - is that not what you mean? They perform the 'create or retrieve' step, either from a prefab or resourcePath


if (obj)
{
obj.OnRemovedFromPool();
}

return obj;
}

public override void Add(PoolableComponent obj)
{
if (obj != null)
{
obj.OnAddedToPool();
pooledObjects.Enqueue((T)obj);
}
}
}

private static Dictionary<Type, AbstractPool> poolLookup = new Dictionary<Type, AbstractPool>();

public static T Instantiate<T>(T original = null) where T : PoolableComponent
{
T obj = null;

if (PoolExists(typeof(T)))
{
obj = GetFromPool<T>();

if (obj != null)
{
if (original != null)
{
obj.CopyFrom(original);
}

return obj;
}
}
else
{
CreatePool<T>();
}

return obj ?? GameObject.Instantiate<T>(original);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either line 72 needs removing or this line needs to be return GameObject.Instantiate<T>(original);. The reference to obj will always be null if the program reaches here.

}

public static T Instantiate<T>(string resourcePath) where T : PoolableComponent
{
T obj = null;

if (PoolExists(typeof(T)))
{
obj = GetFromPool<T>();
}
else
{
CreatePool<T>();
}

return obj ?? Resources.Load<T>(resourcePath);
}

public static void Destroy(PoolableComponent obj)
{
if (obj == null) return;

if (PoolExists(obj.GetType()))
{
ReturnToPool(obj);
}
else
{
Destroy(obj);
}
}

private static void CreatePool<T>() where T : PoolableComponent
{
if (PoolExists(typeof(T))) return;

poolLookup.Add(typeof(T), new Pool<T>());
}

private static Pool<T> FindPool<T>() where T : PoolableComponent
{
if (!PoolExists(typeof(T))) throw new KeyNotFoundException(typeof(T).ToString());

return (Pool <T>)poolLookup[typeof(T)];
}

private static bool PoolExists(Type type)
{
return poolLookup.ContainsKey(type);
}

private static T GetFromPool<T>() where T : PoolableComponent
{
return PoolExists(typeof(T))
? FindPool<T>().Remove()
: null;
}

private static void ReturnToPool(PoolableComponent obj)
{
if (!PoolExists(obj.GetType())) return;

poolLookup[obj.GetType()].Add(obj);
}
}
}
13 changes: 13 additions & 0 deletions Utils/ObjectPool.cs.meta

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.