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.

Bug 53801 - Test and measure the amount of memory needed to open one file in editor
Summary: Test and measure the amount of memory needed to open one file in editor
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 4.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: rmatous
Depends on:
Reported: 2005-01-21 12:18 UTC by Jaroslav Tulach
Modified: 2008-12-22 19:56 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

The way how could be meassured (1.75 KB, text/plain)
2005-02-15 18:42 UTC, rmatous
diff with proprosed NbTestCase.assertSize (1.67 KB, patch)
2005-02-15 18:59 UTC, rmatous
Details | Diff
test that proves that number of files in folder doesn't play role (1.04 KB, text/plain)
2005-02-16 11:18 UTC, rmatous

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2005-01-21 12:18:12 UTC
As adviced in the opinion document
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.
Comment 1 rmatous 2005-02-15 18:38:04 UTC
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.

Comment 2 rmatous 2005-02-15 18:42:10 UTC
Created attachment 20354 [details]
The way how could be meassured
Comment 3 rmatous 2005-02-15 18:59:55 UTC
Created attachment 20355 [details]
diff with proprosed NbTestCase.assertSize
Comment 4 Jaroslav Tulach 2005-02-16 08:08:29 UTC
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 The occupied memory 
shall be the same in masterfs, or am I wrong? 
Comment 5 rmatous 2005-02-16 11:15:27 UTC
 *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. 

Comment 6 rmatous 2005-02-16 11:18:08 UTC
Created attachment 20365 [details]
test that proves that number of files in folder doesn't play role
Comment 7 Jaroslav Tulach 2005-02-16 12:27:59 UTC
Re the test: I thought you will use 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. 
Comment 8 rmatous 2006-06-29 08:39:32 UTC
Fixed: "Tests for measuring size of FileObj,FolderObj"
BaseFileObj 1.22
FolderObj 1.21
FolderObjTest 1.15