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.
During startup of IDE or changing workspaces, all components are being fully opened, their open method (which is usually time-consuming) called. However, it can be optimized so that *only visible (selected)* components in tabbed panes are actually fully opened. Other components needs only to be instantiated (deserialized) and able to return name, display name and icon. To prevent from long pauses after switching between not-yet-initialized components, these not initiallly visible components should be loaded in background thread running on minimum priority, so that when user switches for example between editor components, they are already prepared to appear quickly. Probably not very easy to implement, but IMO it's worth. I'll provide numbers of how it can affect startup time soon.
What you mean they are deserialized, and able return icon and name, dipslay name. There is already such support -> componentShowing method, were the necessary GUI init is needed.
I'll try to explain our misunderstanding and make things clearer: 1) I know about componentShowing, but it's unfortunately not enough (or doesn't work?), at least in currect shape. My measurements show that editor documents are still being loaded, fully initialized even if they are not showing. 2) I forget that deserialization of TopComponents is also very time consuming. In the light of last measurements, ideally invisible top components shouldn't be even deserialized during startup. My measurements attached: Testing conditions: PC Dell Pentium III, 600Mhz, 512 MB memory, JDK 1.4.1, Netbeans Main trunk build, mounted examples local filesystem, opened 8 java source files, 3 text files. Only one textual file was visible (readme.txt) so no java editors should grab startup time. Results: - 25% of winsys init time spent in editor init - another 25% in deserialization of TCs - init of editor component also polluted to request processor
Created attachment 7970 [details] AWT thread times
Oops, sorry, last sentence in previous writing isn't true. Request processor worked on text editor init, not java editor, which is ok. Of course, 25% of time is spent by *java* editor init, this is what is wrong. Apologize for not being clear.
FYI Peter, don't pay much attention to absolute numbers from optimization tool, they're distorted. But percentages are real.
To points: 1) As I described already in issue #19038 and issue #23340, it is problem of editor module it is loading options (etc.) for all editor kits even only one of them is necessary. In your described case componentShowing is called on component with textual object only, (what is ritght), which in turn inites the JEditorPane and only textual editor kit is demanded -> the rest is up to editor module. I claim it fails to do the thing. 2) Avoiding deserialization of TC would take much more of work. I guess it is not possible in short timeframe and wonder it is worth doing that.
answers: to 2) agreed, it would take some work, and first issue will be easier to solve - see comment below. to 1) created issue #28870 to adress problem with initialization of editor kits. But beware!, issue we're talking about here is broader, can't be reduced to just editor. Once again: Winsys shouldn't call open(..) on topcomponents that are invisible during startup. This is not solvable in any module, must be solved in winsys directly.
Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it.
issue doesn't apply to new window system - verified