Published by Adam Myatt on 09 May 2008 at 03:51 pm
NetBeans Module Automatic Unload
As a quick follow-up to my previous post on the NetBeans Feature on Demand, I was thinking about how nice it would to further optimize the NetBeans startup time (via module unloading).
When NetBeans loads, it processes and loads each module that is active. To speed up this process I manually uninstall modules I know I will never use, as well as deactivating modules I use infrequently. It would be nice if the IDE could monitor and do this for me.
NetBeans already has a module called the UI Gestures Collector. The NetBeans team has used this to gather intelligence on what toolbars, menus, and keyboard keys NetBeans users actually use. There’s no reason they couldn’t further augment this to specifically identify which modules are not being called often or at all. Then these modules could be safely deactivated (but left installed). This could be useful since some users may not deactivate certain modules if they aren’t 100% clear that they may or may not use it. This in turn could help speed up the load time in the long run, especially as NetBeans collects more and more data on which modules you do and do not use.
Some specific items to consider for this type of functionally:
- make a variable in the Options section to enable/disable this feature (or perhaps a checkbox field in the Plugin Manager itself).
- provide a variable to allow the user to specify that IF NetBeans decides to turn off an unused module that it should do so silently, or prompt the user to confirm before deactivating.
- perhaps (and I’m not really sure on the value of this one), a setting could be provided that lets the user specify a frequency threshhold that is used by the module deactivation algorithm in deciding if a module should be deactivated.
- tie this into the Feature On Demand capability so that if a user clicks a menu item or activates a project wizard, the feature can be re-enabled automatically.
4 Responses to “NetBeans Module Automatic Unload”
Leave a Reply
You must be logged in to post a comment.
wadechandler on 10 May 2008 at 6:54 am #
The only problem I see is that modules really need to be subscribers to on-demand. There needs to be a new set of manifest entries/keys which tell the module system a module either subscribes or it does not, but yes this would be a good idea.
The reason one needs to subscribe is all of the actions will need to be available some how, and those actions classpaths will need to be available. It seems along with subscribing a new model is needed to support modules overall in the on demand features so that specifics of the classpath may be left loaded in memory while others are left out until needed or that in the layer.xml a module may define actions and other UI information which may be provided for the user so they may enter into specific actions without the full module really being loaded.
For instance, if a modules only user interface entry point is an action, then if it is deactivated it won’t show up for a user, and they’ll never be able to use it without first manually activating it.
So, definitely would be good, but will take more thought and resources than is in the current design of the on demand features, and it would need to be a system wide design outside of just the UI gestures module.
wadechandler on 10 May 2008 at 7:11 am #
I noticed in Geertjan’s blog there are new layer entries for support etc. This goes further than the Wiki document. That looks more like what I was talking about, so it seems it is to the point that modules may subscribe to feature on demand. The only thing I wonder is if the design will/does support any type of action. Some NB actions provide popup menus etc. I note the Wiki document details only for top level menu items, but as you noted it is still under design and in the process of being worked out. Maybe they have some new ideas which haven’t made it into the Wiki page such as allowing a module to provide a JavaFX script chunk for the menu or something along those lines. That would allow more complex proxy menus before the real classes get loaded. Anyways, I’m looking forward to studying it deeper. I wasn’t aware it had progressed further than what is on the Wiki page.
wadechandler on 10 May 2008 at 7:24 am #
Well, I guess my last comment is mute as there are proxy modules being installed which technically any object should be able to be loaded from, I suppose they are detailing top level menus as any standard way of creating an action from the layer should be able to work. I think I’ll just wait for more documentation on what is being worked on :-D
Adam Myatt on 11 May 2008 at 8:51 pm #
I was really just talking out loud and hoping. The Feature on Demand seems decent as it has already been developed (even though Geertjan made clear it is a tentative feature, and certainly not locked in stone - definitely an experiment). The automatic module unload capability is just wishful thinking (if it makes sense). We’ll see what happens.