Hi Gunnar,
> I'm working on a dataset composed of 90000 points and 450000 tetrahedras.
> I'm using this information to create a DelaunayCustom( pts, elms ). Then I
> feed the triangulation to an IrregularSet3D(type, pts, null, null, null,
> delaunay) and use it as set for a field. I then construct a neighbor
> matrix and extract the boundry from it. My memory estimates suggest that I
> shouldn't need much more than 50Mb for this. When I run my application it
> was on 35 Mb before started the Delaunay constructor. It then immediatly
> jumped to 68 Mbs and then processed for a while (1 minute or so). Then it
> jumped to 87Mbs. When I called the irregular set constructor and placed the
> field values (by reference), it jumped up to 147 Mbs. By the time I
> finnished processing the boundry and displaying the data it had consumed
> roughly 180Mbs. It sees a little bit too much...
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 saw in the sourcecode that both the constructor to DelaunayCustom and
> Irregular3DSet copies input data. They do contain constructors for
> disabling copy but these constructors are declared "friendly" and thus not
> accessible outside the visad package. I do not need the arrays after
> feeding them to the Delaunay and set, so even if they rearrange or modify
> them it doesn't matter. This seems like a huge waste of memory.
Making the constructors with the "boolean copy" argument public
allows applications to alter the internal data of these objects
after their constructors have tested them for consistently and
built other dependent internal data. This can cause very
difficult-to-diagnose bugs.
However, we have been making the constructors with "boolean copy"
arguments public in other classes, so in the next source release
I will make these public for DelaunayCustom and all Irregular*Set
and Gridded*Set classes. Meanwhile, you can do the same in your
source.
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.
> Another thing? Is the neighbor matrix for elements available in a Delaunay?
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).
> I also noticed that storing arrays [n][4] takes about twice as much memory
> as [4][n] since each of the n arrays are new objects containg a length
> field and possibly other object data.
Seems plausible given our experience with Java memory
performance. Most internal VisAD data is organized as [4][n]
for efficiency.
Cheers,
Bill
----------------------------------------------------------
Bill Hibbard, SSEC, 1225 W. Dayton St., Madison, WI 53706
hibbard@xxxxxxxxxxxxxxxxx 608-263-4427 fax: 608-263-6738
http://www.ssec.wisc.edu/~billh/vis.html
