best practice threejs geometry disposal? - three.js

Question

If I have something like the following:
myObj = new THREE.Object3d;
scene.add(myObj);
doIt();
function doIt(){
var geometry = new THREE.SphereGeometry( 1, 8, 8 );
var mesh = new THREE.Mesh( geometry, meshMaterial );
myObj.add(mesh);
}
as far as I understand, the variables geometry and mesh get unassigned as soon as the function concludes. But the scene object still contains myObj, which still contains the mesh, which still contains the geometry. So now the geometry lives within myObj within scene. Am I getting it right so far?
But if I then do
scene.remove(myObj);
and also
myObj = new Object();
Then I would think there is no more mesh, no more geometry. I no longer have any extant variable or object which contains or refers to those things. But they still exist somewhere, taking up memory?
There is a dispose() function in three.js, but I don't understand where in my sequence of code it should be normally applied, or exactly why?
I am working on a project which needs to create and then remove lots of objects, so I'm afraid if I don't do it right, there will be performance issues.
Any wisdom much appreciated.

Answer 1

In javascript, objects exist in memory until they are cleared out by it's garbage collector. By assigning a new object to the variable, you are basically just creating a new variable with the same name. The old data still exists in memory until the garbage collector runs and removes the old data from memory.
Since JavaScript's memory is only cleared out by the garbage collector, and you can't manually trigger a garbage collection (and you shouldn't have to), you should use object pooling instead of creating a ton of disposable objects.
Note: This doesn't mean you should always use object pooling, but rather, you should use an object pool if you find yourself creating and dereferencing a large number of objects within a short time span.
Remember, don't optimize prematurely.
In simple terms, object pooling is the process of retaining a set of unused objects which share a type. When you need a new object for your code, rather than allocating a new one from the system Memory Heap, you instead recycle one of the unused objects from the pool. Once the external code is done with the object, rather than releasing it to main memory, it is returned to the pool. Because the object is never dereferenced (aka deleted) from code it won’t be garbage collected. Utilizing object pools puts control of memory back in the hands of the programmer, reducing the influence of the garbage collector on performance.
source
You can find various object pool boilerplates online, but here's an example: https://gist.github.com/louisstow/5609992
Note: there's no reason to keep a large pool of excess objects in memory if you are no longer creating a large amount of objects. You should reduce the pool size, freeing the unused objects, and allowing the GC to collect them. You can always increase the size again if you need to. Just don't switch between shrinking and increasing the pool size too quickly, otherwise you would just be defeating the point of an object pool.
var objectPool = [];
var marker = 0;
var poolSize = 0;
//any old JavaScript object
function commonObject () { }
commonObject.create = function () {
if (marker >= poolSize) {
commonObject.expandPool(poolSize * 2);
}
var obj = objectPool[marker++];
obj.index = marker - 1;
obj.constructor.apply(obj, arguments);
return obj;
}
//push new objects onto the pool
commonObject.expandPool = function (newSize) {
for (var i = 0; i < newSize - poolSize; ++i) {
objectPool.push(new commonObject());
}
poolSize = newSize;
}
//swap it with the last available object
commonObject.prototype.destroy = function () {
marker--;
var end = objectPool[marker];
var endIndex = end.index;
objectPool[marker] = this;
objectPool[this.index] = end;
end.index = this.index;
this.index = endIndex;
}
//make this as big as you think you need
commonObject.expandPool(1000);