Any work on cutting down the memory usage?

[steffen]

If you are not at the latest svn. version the factory might be set as a geometry attribute. In any case you should check that the geom factory is in fact gc'd. either use a reference queue or overwrite finalize and make a printout there. otherwise the test doesn't give much information...

Charles: can you please remove the setter for storing the factory in the geom? If we really need that it should be a static utilily method - but imho this should not be in the API.

[STRESS]

Thanks Steffen, that's actually some crucial information I was missing. That would explain some behaviour I have been seeing before with non inlined arrays and indeed you are right the factory isn't gced. I can even see the reference in the mem profile hanging around.

However, in this particular case I don't think it should make a difference since it will just have another reference to the same double[] as DoubleDoubleArray.inlined and all it's parent classes upwards. Unless there is something else I am not aware of.

[steffen]

no, the factory has (at least) one copy of the data... when you call factory.update() the data is copied into the geometry. it needs to be done this way to have consistant data and thread safety.

[STRESS]

Aha thanks Steffen, yes removing the reference halfs the memory usage again :). Excellent! Well done! I am very happy now!

[gunn]

STRESS,

Just checking that this thread has been satisfactorily resolved.

1. What did you have to do to get the factory to be gc'ed?
2. Could you run the same statistics with jprofiler as in your post of March 26, on the current state? I would still be interested to know how much memory is used by the geometry w/o the factory hanging around. I think it's important if we can provide this information in the documentation, so users know what kind of overhead they have to expect.

Thanks.

[STRESS]

Hello gunn,

Thanks for your concern on this.

STRESS,

Just checking that this thread has been satisfactorily resolved.

I am reasonable happy yes there is still room for further improvements but I am not so concerned right now.

1. What did you have to do to get the factory to be gc'ed?

The problem went away when I updated geometry or scene directory from the repository some of the AbstractSets holded a reference to the their factory that has recently been changed.

2. Could you run the same statistics with jprofiler as in your post of March 26, on the current state? I would still be interested to know how much memory is used by the geometry w/o the factory hanging around. I think it's important if we can provide this information in the documentation, so users know what kind of overhead they have to expect.

Thanks.

Sure that's what I'll get on a 1024x1024 now:

Total mem usage: 193Mbyte

Top three:

1. de.jreality.scene.data.DoubleArray 81Mbytes
2. double[] 57Mbytes
3. int[] 41Mbytes

So as you can see you still could avoid DoubleArray which is now the largest memory holder since that is just used as a caching structure with reformated layout if I understood the code correctly and I made a change once in PointSet which made it disappear while playing around but in the end I couldn't be bothered.