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.
It is necessary to measure the amount of memory occupied by an instance of AbstractFolder or AbstractFileObject in order to understand its overhead and in order to setup some goals for improving it. The interesting values are - how much memory folder and leaf occupies after initialization, how that changes after some operations (getDate, add...Listener, etc.) and find out how that could be improved especially when considering example of having a directory with 10000 leaf files. Please write a test using assertSize on a FileObject, AbstractFileObject.
I changed summary to better reflect current state - we have AFO wrapped into masterFS by MultiFileObject instances. I am going to compute how big are these structures. 1st observation: o.n.m.masterfs.Delegate keeps both its file change listener and this listeners wrapped into weak listener. Maybe we can save one field.
If I got it right every MasterFileObject takes more than 200 bytes. MasterFileObject - 24 Delegate - 40 delegate - FO secondDelegate - FO weakListener - 24 o.o.u.WeakListener.FileChange 32 o.o.u.WeakListener.ListenerReference 24 j.l.ref.WeakReference (to source) fListener - 16 o.n.m.masterfs.MasterFileObject$FileChangeListenerImpl 16 (lsnr list) array in lsnr list 16 (ResourcePath) 24 String in ResourcePath chars in path
MultiFileObject are not better. I see ~1500 instances in my IDE, each one brings >216 bytes and often more (synced ArrayList if there is some lsnr and HashSet for delegates). At least we should create the listener list and delegates set of reasonablel size. 10 and 16 are usualy bigger than we need. MultiFileObject - 64 system - FS name 24 (String) char array in name parent - FO listeners - synchronized ArrayList delegates - HashSet weakL = 24 (o.o.f.$Proxy0) 24 o.o.u.WeakListener.PRoxyListener 32 o.o.u.WeakListener.ListenerReference 24 j.l.ref.WeakReference (to source) lastAttrcacheName 24 - String char array
And now AbstractFileObject/Folder. For a file w/o listeners it can be something more than 160 (depending on name length). For a folder with initialized children it is aproximately 312 + 60 * #children + "char arrays to keep names of children (are these Strings shared?)" + 4 * #lsnrs At least do not use Boolean to mark folders, again proper sizing of listener list can help, map of children is already sized according to count of found files. Do we need Date? Would it be enough to have long timestamp? AbstractFileObject - 56 system - FS name - 24 String char array parent - FO validFlag - boolean validRoot - AFF children - ~12 bytes overhead array of children map - 40 HashMap - only good for folders entries array entries String reference to AFO listeners - 32 ListenerList listenersList - 32 j.u.Collections$SynchronizedRandomAccessList list - 24 ArrayList sized to 10 by default array of elements listenerArray lock - 8 folder - 16 Boolean !!! lastModified - 24 java.lang.Date
This is a remainder to you, the owner of this bug, that this issue has P3, is reported against 4.0 and its target milestone has not yet been set. Please set the milestone, fix the issue or change its priority by tomorrow. Thank you for helping NetBeans to get ready for code freeze.
Fixed in 4.1 by implementing FileBasedFileSystem.