On Mar 15, 2011, at 6:16 PM, Yang, Ming wrote:
> After some thought and a limited number of tests, I have decided to
> use a similar approach to yours (I have found the true dynamic agent
> creation seems to be slow and the operation of the agent creations
> affects the other agents quite a bit. ) . What I have done is to use
> two data collections to hold agents. At start, I produce more than
> enough agents and put them in the “outside collection” and when I
> need to “create” agents, instead of creating them on the fly, I just
> move the agent from “outside collection” to the “inside collection”
> and when an inside agent needs to be removed, I just do the opposite
> and the agent again is ready to be recycled “recreated” again.
> I think it should be computationally more efficient to have two data
> collections because we only need to check the “inside agent
> collection” when network is called for.
Ming, what you're doing is generally known as creating an Object
Pool. Object pools dated at least since early in Lisp code back when
it was expensive to allocate objects and perform garbage collection.
Nowadays allocation and garbage collection is fast, so object pools
are not used as much.
In MASON the primary costs for making an object would be (1) Java's
object allocator, which is exceptionally fast (2) your constructor
code (3) MASON's code for scheduling the object, which is O(lg n) so
pretty fast (4) Java's garbage collector. Of these four, you can
check to see if the garbage collector is collecting too often -- just
java -verbose:gc ...
You can increase the Java heap space and see if that helps things. To
push it to 500 megs (for example) you can do:
java -Xmx500M -Xms500M ...
If it's not the GC then perhaps you've got complicated constructor
code which isn't getting called if you just pull the object out of the
pool? You may want to double-check that.
At any rate if you go the object pool route, I strongly suggest that
you store your agents with weak references or using a WeakHashMap:
That way if you get low on memory Java can reach into your object pool
and deallocate objects as necessary.