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.
http://wiki.netbeans.org/wiki/view/VW_PerformanceTigerTeam Open the attached web project, and then open all 10 pages, memory jumps about 40-50 Mb Profiling with Jprofiler indicates that there is some issue when the jsp editor is opened. It turns out that when JSP Editor parses the JSP page, a huge data structure, org.apache.jasper.compiler.TagLibraryInfoImpl, is created which contains the information about the TagLibrary and the TLD documentation. Incidently, 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. If there are 10 pages and all 10 pages contain the same namespace declaration - when those 10 pages are opened, 10 instances of TagLibraryInfoImpl are created. The net result is jump in 40-50 MB of memory.
Created attachment 43125 [details] Sample web project
Some comments Petr Pisl: The TagLibraryInfoImpl is a class from jsp parser. The jsp parser has full control over TagLibraryInfoImpl. It's true that we cached the instances of TagLibraryInfoImpl, because jsp parser doesn't cache it and it's always built from scratch. I think it's possible to write the cache that the instances of TagLi braryInfoImpl will be shared per project, not per page. The TagLibraryInfo is needed for code completion of user tags. Regards, Petr Radim Kubacki: I was not sure what is huge TLD when we discussed it with Petr today until I run scan for unusually short/long files in IDE - META-INF/html_basic.tld in /home/radim/devel/nb/nb-all/nbbuild/netbeans/visualweb1/modules/ext/jsf-ri-1.2.jar: is too large (443924 bytes) META-INF/webui-jsf.tld in /home/radim/devel/nb/nb-all/nbbuild/netbeans/visualweb1/modules/ext/webui-jsf.jar: is too large (1773817 bytes) META-INF/webui.tld in /home/radim/devel/nb/nb-all/nbbuild/netbeans/visualweb1/modules/ext/webui.jar: is too large (860380 bytes) Really it makes sense to share results of parsing here. -Radim Sandip Chitale: When I googled for this I saw some email traffic here for using the cache for TagLibraryInfoImpl: http://mail-archives.apache.org/mod_mbox/tomcat-dev/200508.mbox/%3C20050830223936.92459.qmail@minotaur.apache.org%3E http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg74386.html http://issues.apache.org/bugzilla/show_bug.cgi?id=33650 So looks like folks at apache/tomact ran into this. They are talking about some flag -cacheTldXml for JspC. Is that something we should use or look into? http://www.docjar.com/docs/api/org/apache/jasper/Options.html#isCaching() Is it possible to build a cache for the whole IDE instead of per project as long as the location (e.g. xmlns:webuijsf="http://www.sun.com/webui/webuijsf") for the TLD file results in the same location? -- Sandip
This problem was discussed through mail. I will try to fix the problem after feature freeze.
*** Issue 104104 has been marked as a duplicate of this issue. ***
I have still working on this issue. Basically I have to take the jsp parser from Glassfish V2, which means that I have to resolve some other issues before committing this.
Fixed in the trunk. Jsp Parser from Glassfish V2 is used. Checking in external/servlet2.5-jsp2.1-api.jar; /cvs/web/external/servlet2.5-jsp2.1-api.jar,v <-- servlet2.5-jsp2.1-api.jar new revision: 1.3; previous revision: 1.2 done Checking in external/glassfish-jspparser.jar; /cvs/web/external/glassfish-jspparser.jar,v <-- glassfish-jspparser.jar new revision: 1.4; previous revision: 1.3 done Checking in external/glassfish-logging.jar; /cvs/web/external/glassfish-logging.jar,v <-- glassfish-logging.jar new revision: 1.3; previous revision: 1.2 done Checking in jspparser/extsrc/org/apache/jasper/compiler/GetParseData.java; /cvs/web/jspparser/extsrc/org/apache/jasper/compiler/GetParseData.java,v <-- GetParseData.java new revision: 1.5; previous revision: 1.4 done Checking in jspparser/extsrc/org/apache/jasper/compiler/CompilerHacks.java; /cvs/web/jspparser/extsrc/org/apache/jasper/compiler/CompilerHacks.java,v <-- CompilerHacks.java new revision: 1.5; previous revision: 1.4 done Checking in jspparser/extsrc/org/apache/jasper/compiler/ExtractPageData.java; /cvs/web/jspparser/extsrc/org/apache/jasper/compiler/ExtractPageData.java,v <-- ExtractPageData.java new revision: 1.5; previous revision: 1.4 done Checking in jspparser/src/org/netbeans/modules/web/jspparser/JspParserImpl.java; /cvs/web/jspparser/src/org/netbeans/modules/web/jspparser/JspParserImpl.java,v <-- JspParserImpl.java new revision: 1.37; previous revision: 1.36 done Checking in jspparser/src/org/netbeans/modules/web/jspparser/ParserServletContext.java; /cvs/web/jspparser/src/org/netbeans/modules/web/jspparser/ParserServletContext.java,v <-- ParserServletContext.java new revision: 1.13; previous revision: 1.12 done Checking in jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/WebAppParseSupport.java; /cvs/web/jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/WebAppParseSupport.java,v <-- WebAppParseSupport.java new revision: 1.8; previous revision: 1.7 done Checking in jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/OptionsImpl.java; /cvs/web/jspparser/extsrc/org/netbeans/modules/web/jspparser_ext/OptionsImpl.java,v <-- OptionsImpl.java new revision: 1.6; previous revision: 1.5 done