Another huge memory saving can be done by using String.intern() on string objects as they are immutable anyway. I think the latest VM's do some garbage collection on the intern cache so it's not a bad thing to do.
Paul Martin Davis wrote: > I'm almost 100% sure that JUMP treats Coordinate objects as immutable > (at least in the core code. I do know that at least one plugin I wrote > changes the Coordinates in Geometries - my bad!). I think this should > be a firm design principle of JUMP - it's simply not worth the risk to > mutate Coordinates in-place. The same goes for Geometrys, I think. > There's lots of benefits to having immutability, and lots of risks to > not having it. > > So your Coordinate-sharing idea should work. Whether this really makes > much of an impact in the general use case I can't say - it's very > dependent on the nature of the data being loaded. 50% savings doesn't > seem like that much to me - but I guess that depends on whether you are > trying to load a 2 GB shapefile! > > Perhaps this should be called Coordinate-externing, referring to the > similar strategy that Java uses for String constants. > > Another possible option for providing memory savings is to take > advantage of the JTS CoordinateSequence facility, and use > PackedCoordinateSequences for raw Geometry storage. This might give an > even bigger memory savings. But it would *definitely* require changes to > the core, since JUMP was mostly written before the JTS CS was > introduced, so the code assumes it can get down-and-dirty with the > Coordinate arrays in JTS. > > Sascha L. Teichmann wrote: > >> Just for curiosity: >> >> When I load a larger polygon shapefile (burlulc) >> I recognized that the geometries share a lot of >> common vertices. In case of the burlulc layer >> over 1,500,000. >> They are represented by com.vividsolutions.jts.geom.Coordinate >> objects. If a shapefile gets loaded a new Coordinate object >> for each vertex is created. >> >> Now I added a simple TreeMap to the PolygonHandler of >> OpenJUMP's shapefile reader to reuse already created >> Coordinate objects and share them with other geometries. >> >> After loading the data (+ triggering GC) the normal OJ >> uses approx. 124MB memory. After the the shared vertices >> modification OJ uses only approx. 89MB. >> >> My question: May this mod lead to any side effects? >> With JTS? With the CursorTools? >> >> Coordinate objects are not immutable, so I expect >> side effects with e.g. neighboring polygons when >> I edit one of them. >> >> I had a brief look at the code and played with >> the CursorTools but I haven't found any side effects >> yet. >> >> This idea comes from playing with OJ on a boring >> friday evening. It only costs me a few seconds to >> implement and if you say "This idea is plain stupid!" >> I'll drop it immediately .. ;-) >> >> Kind regards, >> Sascha >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> >> >> > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
