NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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
visad archives: