DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=33650>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33650 ------- Additional Comments From [EMAIL PROTECTED] 2005-08-22 11:20 ------- (In reply to comment #30) > As the current code only caches the result of the xml parsing it should > translates in roughly a 30% speedup for Liferay compilation. There's weird stuff going on, though. Maybe I did something wrong when applying the patch. Before trying to debug, I'll try to see if caching the TaglibInfoImpl works better. > Liferay being static include happy, it is a good testcase as well. The xml > parsing was the easy part :) As Remy mentions there is load of improvement in > there as the JSP parsing is obviously not very efficient. > > As a side note, I'm nit-picking but I think it would be better to have a > single method that returns the TreeNode. here I feel like they are 2 pieces > of > code related to 'is cache in use'. > > 1) getOptions().getCachedTldXmlMap() return the map or null > 2) if (ctxt.getServletContext() instanceof > org.apache.jasper.servlet.JspCServletContext) is used to figure out if it > should look into the cache (why not checking if the map is null or not ?) > > I might be missing something, but this if is confusing me. Yes, it could be better. I assume the cache map will eventually be used for more than TaglibInfoImpl. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
