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.
netbeans 6 daily build 200705291200 Change a component's id in property sheet, a glass clock shows up. It takes about 3 seconds. It is slower than netbean 5.5.1
My analysis shows (using JProfiler) most of the time is spent in designer in computing the Style Map. See bug http://www.netbeans.org/issues/show_bug.cgi?id=103164
My analysis shows (using JProfiler) most of the time is spent in designer in computing the Style Map. See bug http://www.netbeans.org/issues/show_bug.cgi?id=106724
*** Issue 106724 has been marked as a duplicate of this issue. ***
Created attachment 44373 [details] 5.5 version of the Winstons designer perf sample project
There I added the 5.5 version of the Winston's project (see the issue #106724), trying to look for a regression. It seems it is not true that it got slower (actually it seems a bit opposite), but in the end, it is about the same slow like it was before. I am gonna try to compare it with more old versions, but at this moment this doesn't seem to be a regression.
I found that even the source element is not replaced (only the attribute is changed) all the corresponding rendered elements (in the tree starting with the changed element) are replaced, that caused the designer to relayout and repaint completely. Investigating where this replacement of the rendered elements happens.
It seems it is standard handling by the impl. If bean's property changes, the bean is renrendered, i.e. new rendered structure is created, and that causes to relayout/repaint the entire designer. See the DomSynchronizer#processUpdates.
Created attachment 44489 [details] 1st attempt, hitting deeper issue
The 1st attempt (see attachment), fixes the updating of the rendered document, i.e. when only attributes change, the original nodes are updated, not replaced by the new nodes. This allows the designer to update the corresponding boxes, instead of relayout of entire page. This way the designer relayous only the changed box (and its children). Problem is, that the relayout is the real issue, that is the slow part, probably due to recomputing of the positions, sizes, etc. Issue is also when property which doesn't affect the layout has changed, it is not reflected (only the layout properties). So the above fix doesn't work at the end, even it is correct as a first step to the fixing. In sum, it seems that the performance issue is the implementation of the layout of the box model is not scalable, and that is the core of the designer.
1st part of the fix. Reusing the rendered elements, for the case only the attributes has changed. In that case the attributes are updates and the elements are reused. The save is minor however, because there is still recomputing of the styles and recreating of the style maps for the updated elements and also recreated boxes for the updates elements. Investigating further, but at this moment it seems to fix this issue would require comprehensive reimplementation of the css engine and layout in the designer. Checking in visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/FacesPageUnit.java; /cvs/visualweb/insync/src/org/netbeans/modules/visualweb/insync/faces/FacesPageUnit.java,v <-- FacesPageUnit.java new revision: 1.10; previous revision: 1.9 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/DesignerServiceHackImpl.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/DesignerServiceHackImpl.java,v <-- DesignerServiceHackImpl.java new revision: 1.14; previous revision: 1.13 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/DomSynchronizer.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/DomSynchronizer.java,v <-- DomSynchronizer.java new revision: 1.10; previous revision: 1.9 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/JsfForm.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/JsfForm.java,v <-- JsfForm.java new revision: 1.91; previous revision: 1.90 done Checking in visualweb/designer/markup/src/org/netbeans/modules/visualweb/designer/markup/RaveElement.java; /cvs/visualweb/designer/markup/src/org/netbeans/modules/visualweb/designer/markup/RaveElement.java,v <-- RaveElement.java new revision: 1.2; previous revision: 1.1 done Checking in visualweb/designer/src/org/netbeans/modules/visualweb/css2/DocumentBox.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/css2/DocumentBox.java,v <-- DocumentBox.java new revision: 1.6; previous revision: 1.5 done
2nd partial fix. Now only the style maps of changed elements (and their children) are discarded, instead of all the newly laid out elements. It means that if changed style of textfield, and therefore its parent gets laid out, only the style of the textfield is recascaded. Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/DomSynchronizer.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/DomSynchronizer.java,v <-- DomSynchronizer.java new revision: 1.11; previous revision: 1.10 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/JsfForm.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/JsfForm.java,v <-- JsfForm.java new revision: 1.92; previous revision: 1.91 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/JsfMultiViewElement.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/JsfMultiViewElement.java,v <-- JsfMultiViewElement.java new revision: 1.25; previous revision: 1.24 done Checking in visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/JsfTopComponent.java; /cvs/visualweb/designer/jsf/src/org/netbeans/modules/visualweb/designer/jsf/ui/JsfTopComponent.java,v <-- JsfTopComponent.java new revision: 1.47; previous revision: 1.46 done Checking in visualweb/designer/src/org/netbeans/modules/visualweb/api/designer/Designer.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/api/designer/Designer.java,v <-- Designer.java new revision: 1.44; previous revision: 1.43 done Checking in visualweb/designer/src/org/netbeans/modules/visualweb/css2/DocumentBox.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/css2/DocumentBox.java,v <-- DocumentBox.java new revision: 1.7; previous revision: 1.6 done Checking in visualweb/designer/src/org/netbeans/modules/visualweb/designer/WebForm.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/designer/WebForm.java,v <-- WebForm.java new revision: 1.169; previous revision: 1.168 done
Peter, Are you planning to look into this issue further ? If not, please mark it fixed.
I was trying to ensure this fix works. There were already two regressions found (and fixed). Now it seems fine. Checking one more time before closing.
Found typo, now fixed to bring back the original fix: Checking in visualweb/designer/src/org/netbeans/modules/visualweb/css2/DocumentBox.java; /cvs/visualweb/designer/src/org/netbeans/modules/visualweb/css2/DocumentBox.java,v <-- DocumentBox.java new revision: 1.13; previous revision: 1.12 done Closing this bug, as it improves this concrete issue. However it needs to be noted that there is a very bad scalability of the original architecture. I.e. the more complex page the worse performance (it seems it is linear or even worse). That is a deep architectural problem, and can't be fixed as a bug, but by complete reimplementation only.