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.
Opening a form takes really long time, especially when done for the first time. Further analysis is needed first.
*** Issue 18994 has been marked as a duplicate of this issue. ***
The feeling of slow opening is worsen by blocking the AWT thread (IDE does not react during opening). Sometimes, text in status bar is not displayed, so it is not apparent whether the form is opening or not (see also issue 18181).
I've done some testing, attaching results... Tried opening three sample forms: small, medium and large. Each was opened four times after starting clean build of NB dev 20020911. A directory containing the forms was mounted firts. Tested on W2K, PIII 733, 512 MB, JDK 1.4.0. Analysis of results coming below...
Created attachment 7391 [details] results of opening small form
Created attachment 7392 [details] results of opening medium form
Created attachment 7393 [details] results of opening large form
The results are presented as lines in following format: xxx - operation (yyy) where xxx is relative start time of the operation (relative to start of whole form open), yyy is time spent in this operation (xxx is sum of all prior yyy) e.g. 4094 - reading form data (12859) means that 'reading form data' began 4094 ms after invoking form opening and took 12859 ms. Comments to observed operations: 'Start - opening form' represents the moment when opening is invoked. The time for this "virtual" operation comprises preparing of persistence manager before it starts parsing the form file. 'XML parsing 1' - first parsing of the form file to see whether the persistence manager understands it 'XML parsing 2' - second parsing of the same file, now with the intention to process it further 'requesting src' - obtaining form superclass from java hierarchy; may wait for unfinished parsing 'reading form data' - going through read XML elements and creating form meta data 'firing form loaded' - initializing other components (like code generator) after form data loading is finished 'creating nodes' - force all nodes (presented in componenent inspector) to be created 'attaching listeners' - attaching various listeners on changes in form properties, form options, TopCmponent activation etc 'activating workspace' - activating GUI Editing workspace 'opening java editor' - opening the java file in source editor (does not include validating and painting) 'constrcuting GUI (form view)' - creating form designer, component inspector, and palette (as TopComponents) 'openForm done, now painting' - validating and painting whole form editor. 'repaint done' - form editor is opened and responsible These all operations are performed in one thread, but they still can be influenced by background processing (e.g. java parsing). Profiling should give more information about this.
ANALYSIS The results show two important facts: (1) opening form the first time after starting the IDE is significantly slower, (2) the time spent by reading the data and creating the metadata grows rapidly with number of components in the form. (1) is caused by many things: (a) form editor classes must be loaded and initialized, (b) parsing java files is done - on background, but 'requesting src' must wait on it for certain time, (c) workspace is switched from 'GUI Editing', (d) various global listeners (in 'attaching listeners') must be created, (e) Component Palette and Componnet Inspector, which are singletons must be created. (2) is represented by 'reading form data' operation. It is mainly dependent on size of the form, less on whether the form is opened for the first/second/third... time. Some other remarks: - XML parsing seems to be quite fast, not affecting the performance, - 'opening java editor' is always significantly longer for the *second* opening (proved for all form sizes, repeated several times) - this needs further investigation.
FURTHER ANALYSIS, IMPROVEMENT SUGGESTIONS Going through the list from above: (1a) Loading classes is unavoidable, but we should try at least to minimize initialization time. From profiling, GandalfPersistenceManager and JavaCodeGenerator initialization seem to be quite costly. For example, GandalfPersistenceManager calls XMLUtil.createDocument which takes long for the first time, and is actually used only for saving. Reducing GandalfPersistenceManager time should improve 'Start - opening form' operation (which is further affected by loading settings in FormEditorSettings and initializing FormUtils class - but this must be done somewhen during opening either). JavaCodeGenerator influences 'firing form loaded' operation. (1b) Waiting on parsing is visible mainly in 'requesting src' operation. Actually, it becomes significant only if the user starts opening right after expanding a folder. But user are often fast here... (Otherwise, parsing the individual class is rather fast.) This time could be probably eliminated if the form editor would not require the form superclass from java src API, but stored it in the form file. (Still there would have to be some check on java src whether the superclass has not changed, but it would not have to be done during opening probably...) Further investigation is needed after implementing this. (1c) Although switching workspace from Editing to GUI editing seems to be rather fast, it could be avoided, if form editor had not its own dedicated workspace. This is matter of issue 23165. (1d) Not a big problem. Attaching listener to palette causes its creation, but it must be done anyway before form opens. (1e) Does not seem to be a big problem. TopComponent descendants creation and initialization might be checked in more details... (2) Profiling shows that manipulation with UIDefaults done when creating components is very costly. Optimization could bring major improvements here. Then further analysis should follow. (other) Although XML parsing does not seem to be a problem, it could be probably avoided to be done two times (when parsing the same file the same way). TODO: 'opening java editor' and 'openForm done, now painting' waiting for further analysis...
*** This issue has been marked as a duplicate of 26581 ***
is not a duplicate...
... but blocking
On the item number 2: (2) is represented by 'reading form data' operation This takes a long time. There was a comment that XML is rather fast. I wonder if this is actually the case. Parsing using SAX is awkard, causing generating alot of code such as swaping in and out handler, definitely can be improved. Parsing using DOM takes a lot of memory, generate the whole data structure, very slow. I don't know which one was used. I strongly believe that moving to the newest java spec on parsing xml, which I interpret as reading the xml top down, but DOM like, would greatly improve performance. This should also apply to the Netbeans xml module in generating parsing code.
Q1: There is a possibility to let the source editor be opened first, then to load and display the form designer itself. So something would "happen" in the middle of opening (source code shows up) - would not this look more "responsive" to the user (however the overall time would be the same)? Q2: Display wait cursor during opening? (I suppose the answer is yes; AWT is blocked...)
A1: Yes, this opening "frame" first and then fill content will be good effect on responsiveness...Is it possible make it simply ? A2: Yes use API of Wait cursor during opening form editor please.
Integrated (1): first, the source editor is opened, then "Loading Form..." appears in status bar and the form opens. Please try how you feel about this change - whether the two-steps opening is more responsive, but not disturbing. Will implement the wait (busy) cursor later. /cvs/form/src/org/netbeans/modules/form/FormEditorSupport.java new revision: 1.109; previous revision: 1.108
Improved performance of reading/creating components (mentioned above under (2)): - fixed a bug with superfluous UIDefaults switching, - optimized properties and events creation (not until needed by property sheet). /cvs/form/src/org/netbeans/modules/form/CreationFactory.java new revision: 1.15; previous revision: 1.14 /cvs/form/src/org/netbeans/modules/form/FormDesigner.java new revision: 1.78; previous revision: 1.77 /cvs/form/src/org/netbeans/modules/form/FormEditorSupport.java new revision: 1.112; previous revision: 1.111 /cvs/form/src/org/netbeans/modules/form/FormLAF.java new revision: 1.8; previous revision: 1.7 /cvs/form/src/org/netbeans/modules/form/MetaComponentCreator.java new revision: 1.36; previous revision: 1.35 Also issue 28595 (editor warm-up) helped in the first open. Now going to verify results.
Tried opening large form in Form Editor (100 components): NB 3.4 NB 3.5 the first opened form 14 sec 7 sec some form already opened 9 sec 3 sec [so both the first and subsequent use significantly improved] Also the UI feedback was improved: - java file opens first, then the form is opening - the opening time is divided so the whole feel is more responsive, - there are two messages in status line (one for java file, one for the form), - mouse wait cursor is set during opening.