Community
Participate
Working Groups
1.5 wtp april 21 In a large project with 200 jsp/html. I ran validation It took a lot of time almost 300 seconds out of which time is spent 120 seconds in XHTMLAssociationProvider.getXHTMLCMDocument(..) here is the breakup Name Time (ms) org.eclipse.wst.html.core.internal.modelquery.XHTMLAssociationProvider.getXHTMLCMDocument(String, String) 119,851 100 % org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.CMDocumentManagerImpl.getCMDocument(String, String, String) 117,642 98 % org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.CMDocumentManagerImpl.loadCMDocument(String, String, String, boolean) 113,341 95 % org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.CMDocumentManagerImpl.lookupOrCreateResolvedURI(String, String) 4,151 3 % org.eclipse.wst.xml.core.internal.contentmodel.modelqueryimpl.CMDocumentManagerImpl.getPropertyEnabled(String) 80 0 % org.eclipse.wst.xml.core.internal.contentmodel.util.CMDocumentCache.getStatus(String) 70 0 % org.eclipse.wst.xml.core.internal.modelquery.XMLCatalogIdResolver.resolve(String, String, String) 2,209 2 % I can send files/projects if neccesary
Created attachment 39827 [details] patch
I think I found the root of the problem, and I implemented a caching mechanism, that helped fix the problem for me. Problem exists in CMDocumentManagerImpl and CMDocmentCache the manager object is created too frequently and does not share the documents in its cache during validation. Infact this cache is created, everytime a utility method is called ? CMNodeUtil.getElementDeclaration(...) calls ... CMDocumentManagerImpl.getCMDocument(String, String, String) calls... loadCMDocument(....) Cache should be shared across instances. I created a cache of CMDocuments that are cleared after 60 seconds after the last reference to it. That way I savefd 113 - 6 = 107 seconds added a patch
Nitin, can you apply that "soft reference" pattern here, that you used in TLD Document manager?
Nitin, did you get a chance to look at this defect ? Its been open for a long time just upping severity so that you can take a look at it.
Lowering back to major after discussing with Raj.
Wow, this problem has such a performance impact. Can you look into its viability for WTP 1.5.2 This affects html validator running on a large workspace with 2-3000 html files
Let's activetly investigate for 1.5.3. I don't like "timed caches" as proposed, but there should be other options available ... and, perhaps, a timed cache would be acceptable here?
This seems a valid hot bug request for 1.5.3. Nitin, please investigate and review patch. Thanks.
Raj, would be alright moving this to 2.0? We already have a 1.5.3 RC in place and I don't quite have this solved correctly.
thats ok
fixed
We're seeing some regression around this change and I'm looking for an alternative approach to solve this. Am I correct to assume that we're mainly concerned with validation performance?
I am re-opening this bug, as I think it is on the verge of being reverted, due to bug 190548. That way "listeners" to this bug can review what's going on in bug 190548. I suspect part of the long term solution is better specifying the API for "getting" content models ... such as if you "get" the model, you must hold a reference to it if using any part of it. And/Or ... perhaps there's some fancy "re-create" options that could be done under the covers if part of a content model discovers its parent had been GC'd.
Any update on this?
Correct caching will either require some sort of arbitrary timer (ick) or a reworking of the framework to track usages, neither of which will be done in the short term.
ping long term is here. :)
This bug confuses me, from what I can tell both #loadCMDocument use the CMDocumentCache and this cache has recently been updated to clear itself when low memory events get sent out. So Nitin, what is the actual status of this bug?
(In reply to comment #17) > So Nitin, what is the actual status of this bug? Your take is as good as mine at this point.
I think some of this was solved in the HTML layer with the cache Nitin put in late in WTP 3.0.*. Recently, Gabriel is working on a global CM document cache. See bug 266683. So I'm thinking we can either close or dup this to bug 266683.
Thanks for your analysis. Duping against Bug 266683. *** This bug has been marked as a duplicate of bug 266683 ***
