This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
As adviced in the opinion document http://openide.netbeans.org/tutorial/reviews/opinions_51551.html the memory consumption should be optimized for opening single file in editor - where parents and siblings are not accessed at all. This used to be problem in the old implementation and we need measurement and not only guesses to ensure us that it has been improved.
There is hard to find the right methodology. Memory consumption depends on many factors. Moreover these factors depends on implemenation. Definitely there can be expected that the longer file path the higher memory consumption. May be the right aproach could be to compare both FileObject instances as from LocalFileSystem as from FileBasedFileSystem. I used org.netbeans.junit.MemoryCounter for computing the size of the object graph. I copy/pasted MemoryCounter into my code but I sugest to add new method assertSize in NbTestCase that would take reference object instead of limit. See attachment with above desribed test. This test passed which should be good proof that FileBasedFileSystem really reduces memory consumption.
Created attachment 20354 [details] The way how could be meassured
Created attachment 20355 [details] diff with proprosed NbTestCase.assertSize
If you need to count instances of objects, you can use filter and pass it to assertGC, no need to copy anything. Comparing with LFS is valuable, and clearly shows the improvement, however it may not be sustainable in future as the impl of LFS could change (I know unlikely, but still local criteria would be better). Moreover I do not understand the asserts. A bit of comments explaining why *10 and *2 would be nice. Could you please measure what it takes to get one fileobject from folder with 1, 10, 100, 1000 java.io.Files. The occupied memory shall be the same in masterfs, or am I wrong?
*10, *5 and *2 - with these figures the test passed. In other words it should be verification of improvement. I just gradually incremented these constants and re-run the test until the test failed. I like relative comparison to FileObject from LocalFileSystem. Sustaining ? Such specialized filesystem like FileBasedFileSystem should ever beat LocalFileSystem based on AbstractFileSystem - no matter how LFS or AFS implemented. If test once fail then there is necessary to evaluate it and probably it will be sign that there is room for improvment. Comparing size of Objects to absolute constants means that on principle these test must ever pass at the start becaue these absolute constants just come from your implementation. Its purpose is to ensure that your later changes won't make memory consumption worse but comparison to LFS FileObjects can also ensure it - that's why I prefer it and then MemoryFilter is of no use for me.
Created attachment 20365 [details] test that proves that number of files in folder doesn't play role
Re the test: I thought you will use java.io.File to create the files (various numbers) and then ask for one fileobject and measure the size or number of FileObject created. I do not know what your test is measuring, but it does not seem to be the amount of memory needed to open "lonesome" file, as in your case there nobody is lonesome - there is 100 siblings.
Fixed: "Tests for measuring size of FileObj,FolderObj" BaseFileObj 1.22 FolderObj 1.21 FolderObjTest 1.15