---

Performance Tiger Team

Goal

A tiger team has been formed to investigate and improve the performance of VW in NetBeans 6.0. The goal of the team is to track down and fix

• Memory Leaks
• CPU Performance
• Memory consumption

Members

• Devanada Jayaraman (Insync)
• Peter Zavadsky (Designer/Outline)
• Quy Nguyen (Memory Leaks)
• Sandip Chitale (Insync)
• Winston Prakash (Designtime/JSF Support/Components/Insync)

Status

Date	Description
16 May 2007	Team formed

A large memory consumption issue was discovered due to the allocation of TagLibraryInfoImpl datastructures for each page (approximately 2 to 3 meg). TagLibraryInfoImpl datastructure is created by the JSP parser and is stored in the NbEditorDocument for the JSP files.

First pass performance results (after implementing Task 1 & 2 below)

Action	With out Fix	With Fix
Create VWP project (new User dir)	30-35 secs (designer to appear)	25-30 secs (designer to appear)
Create second VWP project	6-10 secs (designer to appear)	6-10 secs (designer to appear)
Open first blank page of a project with 1 page (after IDE start)	6-8 secs	6-8 secs
Open first page (lots of components) of a project with 1 page (after IDE start)	13-15 secs	13 - 15 secs
Opening first page (blank) of a project with 128 pages (after IDE start)	2 min 5-10 secs (memory + 30-40 MB)	6-8 secs (memory +10-15 MB)
Opening first page (lots of components) of a project with 128 pages (after IDE start)	2 min 30-40 secs (memory + 100-120 MB)	12 - 15 secs (memory +15-20 MB)

Results after eliminating the call to syncAll()(as per Observation 4) and optimizing findDesignContexts() implementation

Action	With out Fix	After removing syncAll() calls	After removing syncAll() calls and optimizing findDesignContexts()
Adding table component (I time) for a project with 1 page	6 secs	6.3 secs	6.3 secs
Adding table component (II time)for a project with 1 page	1.8 secs	2 secs	1.6 secs
Adding table component (I time) for a project with 128 pages	140 secs	18 secs	7.5 secs
Adding table component (II time)for a project with 128 pages	2.8 secs	7 secs	2.8 secs

Tasks

#	Description
1	IDEA:Generate managed bean crossreference accessors only at the time of creation of the Lifecycle managed beans i.e. AbstarctPageBean, AbstarctRequestBean, AbstarctSessionBean, AbstarctApplicationBean sub classes.

Insync tries to ensure the presence of cross referencing accessor methods based on managed beans scopes during project creation and open. This feature has more drawbacks than the advantages

• They are re-generated even if the user wantingly deletes them.
• User adding life cycle managed bean could result in modification to other life cycle managed beans. This results in versioning problems
• Cost of generating/regenerating them during project re-open affects the startup performance and also during page switching

Many users have been complaining about this. Therefore it has been decided to generate them only when the life cycle managed beans are created

2	IDEA:Investigate if it will be possible to avoid initial call to syncAll() which modes all the Lifecycle managed beans

The initial syncAll() is indeed required to ensure cross referencing accessors for all the life cycle managed beans. As per the first idea, we will not be adding accessors during project open. Therefore it will be sufficient to call syncAll() only during the project creation, in which case it will not be expensive(modeling of 1 page and 3 non-page beans). As and when the user opens other pages, they will be modeled. So, during project open, only the pages which are open and the non-page beans(required by outline) are modeled. This is in a way model on demand. This should provide us huge improvement in performance during the IDE startup with a project open, where in the project has very high number of pages but few of them are open.

TODO: Ensure that syncAll() is not called from some other places

3	OBSERVATION: The measurements are showing that NdEditorDocument for a blank VW page (.jsp) are 3M as opposed to 8K for simple JSF page. Investigate.

Related observation:

1. Start the IDE, create a new project, and then add 9 other new pages, memory consumption is about 75Mb
2. Start the IDE, open a project with 10 pages(all of them open) takes about 40 Mb.

After fixing a typo in the jsp template which we use to create our jsp and a bug in insync code due to which incorrect jsp version was persisted in jsp

1. Start the IDE, create a new project, and then add 9 other pages takes about 40 Mb which matches the above second case.

This clearly indicates that there is some issue when we modify our jsp model. It turns out that when the model is modified the document for the JSP page is loaded. The JSP page refers to the tld for Woodstock or Braveheart components for Java EE 5 or J2EE1.3/1.4 projects respectively. The TLDs for Woodstock or Braveheart components are large as they contain the full information about the component tags. This information is loaded by the JSP parser for code completion using the TagLibraryInfoImpl datastructures (apprximately 2 to 3 megs of data). It turns out that these datastructures are created and held by each of the NbEditorDocument for the JSP files. Thus for each page that is opened a 2 to 3megs of memory is consumed.

Issue # 105427 has been filed.

4	OBSERVATION: Measurements show that Table component takes too long to appear on the designer when dropped first time after opening the project

Investigation results based on Jprofiler profiling data:

Action	Project with one Page	Project with 128 pages	Project with one page (With "fix")	project with 128 pages (With "fix")
First time drop	9-10 secs	70-80 secs	4-5 secs	4-5 secs
Second time drop	3-4 secs	3-4 secs	3-4 secs	3-4 secs

First time drop lag is mostly influenced by insync and partially by designer (see attachment Table_first_drop_call_tree1.html). The second time drop lag is mostly influenced by designer and partially by (see attachment Table_second_drop_call_tree2.html)

Interestingly if you notice, when the table is dropped for the first time on a page with 128 pages (just one page opened), it takes about 70-80 secs. It turns out, when the table is dropped, the dreaded syncAll() is called at two places (See Table_first_drop_call_tree1.html & Table_second_drop_call_tree2.html).

When I commented out the code where getDesignContext() is executed (which in turn calls the syncAll()), the so called "fix" I mentioned in the table (not a real fix, could potentially break other actions like refactoring), the table drop took only about 4-5 secs on both single and 128 page projects.

We need to carefully evaluate the need for getDesignContexts() at org.netbeans.modules.visualweb.insync.live.BeansDesignProperty.toSource() and org.netbeans.modules.visualweb.insync.beans.Bean.setName() to avoid the above performance issue.

On Friday, Jun 1st 2007, Deva created a patch for replacing the use of getDesignContexts() in the above two places. We reviewed the patch on Mon, Jun 05, 2007. It looks good with minor corrections such as use of contsants in place of string literals.

If the above is "corrected", now most of the performance lag is due to designer.

The main culprit seems to be org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap. (see attachment Table_second_drop_call_tree2.html). For every property change in the component the StyleMap is recomputed by batik parser which is the main performance bottle neck. We need to find out if any caching could be done.

The problem is really pronounced when you have many components in the page.

We need to take a look at the code at Batik parser and see what we can do here. Batik code is a hacked version so you can change it if we want. Also need to see if these things are fixed in new version of open source batik parser and check the possibility of merging with our hacked version.

5	OBSERVATION: Insync uses several Retouche modification tasks and commits the modifications after each task. There may be a possibility of caching the modifications starting at writeLock() and commiting them in writeUnlock(). This may improve performance.

Deva is investigating the feasibility of the above approach. Deva please add your observations.

6	OBSERVATION: When a complex page is loaded in to the designer, it becomes very cumbersome to design the page.

While moving around the components or modifying the component properties in a page with complex layouts and compoents it takes several second for the designer to repaint. Designer freezes for several seconds

On a fast machine it takes about 7-10 seconds for designer refresh. On a slow end machine, it takes about 30-40 seconds on a very complex page.

We analyzed the performance using The main culprit seems to be org.apache.batik.css.engine.CSSEngine.getCascadedStyleMap. (see attachments Designer_painting_Call_Tree.html & Designer_painting_Hot_Spots.html). For every property change in the component the StyleMap is recomputed by batik parser which is the main performance bottle neck.

Even when one property changes, other computed properties in the parents and children (inheritance + cascading) might change. so most of the things get recomputed after that. Need more analysis to find if there is a way not to do page layout when modifications made to properties which does not influence the layout at all (e.g renaming the id) or doing a binding that does not change the visual at all.

Issue # 106724 has been filed

Scenarios

(Legend: P - CPU performance, ML - Memory Leak, MC - Memory consumption, OMO - one time memory overhead - such as factories in lookup?)

Full

1. Creation of Web project + VW framework
   1. How long does it takes for the New Project wizard to disappear after the Finish button is clicked? (P)
   2. How long does it take to show the Page1 editor tab after the new project dialog disappears? (P)
   3. How long does the Page1 editor tab show "Loading, Please wait..." message? (P)
   4. How long does it take to drop a component as soon as the functional Designer (with grid pattern) is shown, while the class path scanning is still goin on? (P)
   5. How much is the memory increase with a blank page, classpath scanning finished and double clicking on the Memory meter to do garbage collection? The idea is to determine what is the memory consumption for a minimal project. (MC)
   6. Close the project, double clicking on the Memory meter to do garbage collection. What is the drop in memory usage? (OMO)
   7. Mark the memory usage and VW object counts in profiler tools, reopen and close the project? What is the additional memory memory usage? (ML)
2. How long does it take to drop a table component? (P)
   1. Perform steps 1.5, 1.6, 1.7?
3. How long does it take to drag and drop a database table on to the table component and the table shows the effect of binding? (P)
   1. Perform steps 1.5, 1.6, 1.7?
   2. eplicate (copy paste) the page after step 3, 9 more times, to get total of 10 pages, open all of them, (How much does the memory usage go up? (MC)) shutdown the IDE. Restart the IDE.
   3. How long does it take to show the IDE window? (P)
   4. How long does it take to show Page editors with "Loading, Please wait..." message? (P)
   5. How long does it take to see a functional Designers? (P)
   6. How long does it take to switch between pages? (P)
   7. How long does it take to switch between Designer, JSP editor and Java editor tabs of the same page? (P)
   8. How long does it take to rename the table component's id
4. Do the step 4, but this time with 100 pages. (P)
   1. How much is the memory consumption with 100 pages open?
5. Do the steps 4,5 but this time cleaning up the user dir before the IDE restart. This mean that the project will have to be opened. (P)
6. Do the steps 4,5 but this time cleaning up the var/cache folder before the IDE restart. (P)
7. Do the steap 4,5,6,7 with 2 Projects.

Initial

We will initially concentrate on the following simple scenarios - 1,2,3,4.

Reference

Communications

The nb-perf@sun.com mailing list will be used for communications.

Tools

• NetBeans Profiler
• OptimizeIt (?) 1 2 3

• JProfiler (?)

Issues

This section will show the list of Issues related to VW performance.

Attachments