Hi
> We also often notice that memory use is more than you'd
> expect just by adding up the arrays. Especially when you
> start generating displays. This is just Java memory
> performance problems. Java3D version 1.2.1 should enable
> us to improve this somewhat.
I ran some basic tests, and after what I could see, the memory that is
allocated as part of a method call is not released when it is finnished. At
least not right away. When I repeated the a method call, the VM did not
reuse the allocated memory from the first call, but rather allocated new
resources for each call. Even when I forced garbage collection between each
call. (System.gc() and System.runFinalization()).
> Another approach would be for you to set your arrays = null after
> you have constructed your Delaunay and Set classes, as a way to
> conserve memory.
This method will consume memory over time, when the garbage collector
finally decides to go to work, but it does have a flaws. You allocate a new
set of data before deleting the old one, meaning that you have twice as
much memory consumed, and no control over when the first set is released.
> There is no variable named "neighbor" in Delaunay. However, you
> will note that the arrays in Delaunay are declared public, so you
> can access them (of course, writing into them is a big safety
> hole).
My current method for extracting neighbors has complexity O(num_elms). For
the dataset in question it takes about 30 seconds and 20Mb while computing,
and returns an array of 2Mbs. Since I'm not very familiar with the
implementation if Delaunay I was wondering if any of the public fields
contained information that I could use to better the performance. I could
not find in the documentation what is contained in the edges and walk
arrays. I was hoping that some of this data could reduce my memory
consumation.
Gunnar
