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.
[dev feb 28] Profiling shows that a bunch of strings in the VM are from the Form Editor main bundle, which is probably unnecessary; anyway, it is really big. The following classes hold a static resource bundle: actions/EventsAction.java layoutsupport/AbstractLayoutSupport.java layoutsupport/delegates/GridBagLayoutSupport.java FormEditor.java palette/CPManager.java ComponentInspector.java editors2/BorderEditor.java At least FormEditor is initialized during startup.
BTW easy trick to see when a bundle is loaded: -J-Dorg.openide.util.NbBundle.DEBUG=true and watch the log file.
Static bundle loading in Form Editor... So what should I do? To call always NbBundle.getBundle and hold absolutely no references to bundles? Can I rely on NbBundle doing some reasonable caching? Isn't after all more effective to hold the main bundle staticaly all the time (when it is used often)? BTW the main form bundle is first time loaded by the following: <snip> at org.openide.util.NbBundle.getBundle(NbBundle.java:333) at org.netbeans.core.modules.Module.getLocalizedAttribute (Module.java:231) at org.netbeans.core.modules.NbInstaller.loadSections (NbInstaller.java:360) at org.netbeans.core.modules.NbInstaller.load (NbInstaller.java:207) at org.netbeans.core.modules.ModuleManager.enable (ModuleManager.java:665) at org.netbeans.core.modules.ModuleList.installNew (ModuleList.java:493) at org.netbeans.core.modules.ModuleList.trigger (ModuleList.java:437) at org.netbeans.core.modules.ModuleSystem .scanForNewAndRestore(ModuleSystem.java:272) at org.netbeans.core.NonGui.run(NonGui.java:542) at org.netbeans.core.Main.run(Main.java:231) at org.openide.TopManager.initializeTopManager (TopManager.java:120) at org.openide.TopManager.getDefault(TopManager.java:81) at org.netbeans.core.Main.main(Main.java:383) at org.netbeans.core.TopThreadGroup.run (TopThreadGroup.java:81) at java.lang.Thread.run(Thread.java:484) ----- P.S. > ... anyway, it is really big. 38KB is big?
Petr can give some advice re. holding bundles statically or not. As a rule, use NbBundle.getMessage, and if a given method uses the same bundle over and over, use NbBundle.getBundle as a local var; but do not keep the bundle as a static var. NbBundle does soft caching. 38K is not big but it is held as a Properties object which is probably substantially larger... not sure. Re. being loaded by the module system: yes it is a problem that if you have any tools actions (InstallToPaletteAction), the module's display category is looked up for the purpose of knowing how to group the actions with separators in the Tools... submenu (done acc. to display category). This ought to be fixed with the future Commands API. In the meantime, I might suggest keeping the OpenIDE-Module-* keys in a separate bundle file so that not so much is loaded during startup. (Petr do you think that makes sense?)
Thanks Jesse, I'll try that...
Yes, it does make sense. It is like this: 37Kb bundle file with ~500 items means: ~25K chars -> 50KB ~1000 String instances -> 24KB ~1000 char array overhead -> 12KB ~500 Hashtable$Entry -> 12KB Entry[500] -> 2KB Which is about 100KB in total (I've measured it and it matches, after loading form's properties, heap was 101KB bigger). If every module had its 100KB properties permanently in memory, 5MB of heap will be wasted immediately.
I've removed all static bundle references, and also created a separated bundle for manifest localization. However this freed some memory, I'm not sure about the impact on the performance - tracking the bundle loading it seems it is re-loaded quite often, sometimes even during form opening... I think about creating a hard reference being kept for the time any form is opened. Opinions?
In fact, you could split the bundle even more - to have layer localization in a separate file (say resources/layer.properties) This would shorten the parsing time and you probably don't need both at once (during usual work, the layer bundle will be needed only for New wizard, right?). Bundles are soft-cached, they shouldn't go out too early, but it is VM implementation dependent. Holding bundles: This should be handled at the infrastructure level. What wh probably need is a timed reference, but I'm still thinking how to implement it effectively. Then we can disable freeing of Bundle for first, say, 10s, or even for 10s after last usage. On the other hand, if you know there is a problem during form loading and the form loading goes through a single method (i.e. the bundle is reloaded while the VM is still under that method), you can reference the bundle from a local variable.
*** Issue 29138 has been marked as a duplicate of this issue. ***
Resolved for 3.3.x or earlier, no new info since then -> closing.