[ http://jira.jboss.com/jira/browse/JBIDE-538?page=comments#action_12393593 ] Snjezana Peco commented on JBIDE-538: ------------------------------------- I have reviewed http://jira.jboss.com/jira/browse/JBIDE-538. Starting the VPE editor is very slow because it creates a lot of objects. Starting Eclipse (the Java perspective) with JBoss Tools creates about 700000 objects and starting the VPE creates 800000 additional objects. They are mostly xerces objects (except java.lang) what means that the biggest problem is related to classloading and parsing xml files. You can check this by opening some XML editor and after that the VPE editor. Opening the VPE editor will be faster. There are some more issues with the VPE editor. They are the following: 1) When starting the editor, preview and visual part are always started You can check this in the following way: - open some JSP file in the VPE editor and select the Source tab - set a breakpoint on init/createPartControl of the MozillaEditor and of the MozillaPreview - open the same file again The MozillaEditor and MozillaPreview's methods are called although only the Source tab is shown. In addition, the JSPMultiPageEditor.createWindowsPages() method calls the addPage method 4 times (for every editor's page), creates JSPMultiPageEditorSite 4 times, adds propertyChangeListener 4 times. 2) There is a memory leak in the VPE editor This is the test case: - show heap status - open 3 files in the VPE editor - close all the files - call the Garbage Collector - open the same files in the VPE editor - close all the files - call the Garbage Collector Memory usage will be increased by 5 MB and more. Repeating these steps will be increasing memory usage permanently. 3) When creating DocumentBuilder (XMLUtilities.createDocumentBuilder) JBossTools unnecessary creates thread (and waits). Creating a context classloader is also unnecessary because xerces uses the context classloader correctly. Attached is a patch which solves the mentioned issues. 1) Mozilla Visual Editor and Preview are created lazy what speeds up starting the editor. If the file is opened in the Source tab (test case 1), the Mozilla Editor and Mozilla Preview won't be created. On my machine, opening home.xhtml (from a Seam project) lasts about 11 sec the first time with the standard JBoss Tools; after applying the patch, it lasts around 10 sec. However, if the Source tab has been selected, opening the file takes about 6 sec (11 sec without the patch). Opening the XML editor takes cca 4 seconds. If the XML editor was previously opened, opening the VPE editor takes less than 2 sec when the Source tab is active and about 5 seconds if the Visual/Source tab is active. This means that classloading is the main culprit for slow opening the editor. 2) You can try the above mentioned test case after applying the patch The causes of the memory leak are the following: - some listeners aren't removed - JSPMultiPageEditorSite isn't disposed - mozilla listeners are removed too late (they can't be removed in the dispose method because the mozilla editor is already disposed) - KbConnectorFactory remembers KbConnector after closing the editor. This connector causes a lot of classes to be retained in the memory. Mozilla and the SWT Browser widget (org.eclipse.swt.browser) are being leaked when opening/closing the VPE editor, but this behavior is the same for the ATF project and for Snippet267. I suppose that this is a bug in the Eclipse browser implementation. 3) A minor enhancement Separating source and visual part can be of use when analyzing http://jira.jboss.com/jira/browse/JBIDE-675 and http://jira.jboss.com/jira/browse/JBIDE-1105 . Further enhancements can be done by running some procedures in the background during Eclipse startup. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira