Community
Participate
Working Groups
For our test case (opening jsp file which has custom tag), sse version of JSPModelQueryImpl.getCMElementDeclatation() takes only 281ms, but now wst version takes 3,702ms! Most of time is consumed in HTMLModelQueryImpl.getCMElementDeclaration(). (These figures are by cpu sampling of YourKit 3.0) I also measured cpu tracing of YourKit 3.0 and found that invocation count of JSPModelQueryImpl.getCMElementDeclatation() decreases from 26,234 to 21,200, though Time(ms) increases about 4 times.
Could this be related to the XMLIdResolver class changing from accessing just the XMLCatalog to using the extensible URI resolver (and all of its extensions) between IBM's initial contribution and now?
CCing Craig for comments on XMLCatalogIdResolver (which sure *sounds* like it's only supposed to query the XML Catalog).
And this time I mean it.
As I recall XMLCatalogIdResolver used to ... way back in the old days.. only use the catalog. Then we invented the common resolver we changed the code so that XMLCatalogIdResolver called out to the common resolver. So the name 'XMLCatalogIdResolver' is misleading. We do expect it do more than just catalog resolution. As stated in the TODO at the top of this class we need to remove this class entirely and use the common resolver directly. This change will cause some difficulty in other places in the code however so it's not a small piece of work. Perhaps for now we should simply rename this class URIResolverDelegate (or something along those lines).
(In reply to comment #4) > We do expect it do more than just catalog resolution. Why?
I profiled the scenario... yes, this regression is caused by the XMLCatalogResolver. In short, most of the time was spent in the ExtensibleURIResolver, in which turns calls the o.e.wst.common.componentcore.internal.util.ComponentResolver. For more details, see the stack trace below: org.eclipse.wst.xml.core.internal.modelquery.XMLCatalogIdResolver.resolve(String, String, String) 4,456 98 % 0 org.eclipse.wst.common.uriresolver.internal.ExtensibleURIResolver.resolve(String, String, String) 4,456 98 % 0 org.eclipse.wst.common.componentcore.internal.util.ComponentResolver.resolve(IFile, String, String, String) 4,356 96 % 0 org.eclipse.wst.common.componentcore.internal.resources.VirtualFile.getUnderlyingFile() 1,632 36 % 0 org.eclipse.wst.common.componentcore.internal.resources.VirtualResource.getWorkspaceRelativePath() 1,562 34 % 0 org.eclipse.wst.common.componentcore.ComponentCore.createResources(IResource) 1,081 24 % 0 java.net.URL.<init>(String) 40 1 % 0 org.eclipse.core.runtime.Path.<init>(String) 20 0 % 0 org.eclipse.core.internal.resources.Resource.getLocation()
The ComponentResolver only comes into play in a project with the module core nature and its support for a flexible layout. Should the XMLCatalogIdResolver keep calling the common URI resolver or directly call into the catalog extension?
Some more investigation..... When the JSP is opened, the ComponentResolver.resolve() method is called 1866 times. Out of these 1866 times, 1863 of them have "" as the systemId input argument. Instead of working thru all the resolve logic (which is where most of the time was spent), can we just check for the zero length systemId and return immediately?
In ComponentResolver.resolve(...), I changed: if (systemId == null) { if (_DEBUG) { System.out.println(" (no system reference)"); //$NON-NLS-1$ } return null; } to: if (systemId == null || systemId.length() == 0) { if (_DEBUG) { System.out.println(" (no system reference)"); //$NON-NLS-1$ } return null; } The time spent in this method went down from 4.3 sec to ~0.
Fixed, see bug 155572 for remaining issues.
Verified.
