Community
Participate
Working Groups
In our test case (build lage project), org.eclipse.wst.sse.core.internal.model.ModelManagerImpl.createStructuredDocumentFor(IFile) shows regression compare to previous product. For 969 times invocation, AbstractDocumentLoader.createNewStructuredDocument(IFile) takes almost same time before (4,300 msec). While ModelManagerImpl.calculateType(IFile) takes about 3,800 msec. This method is not shown in profiler (YourKit3) before. Most of time is consumed in CSSResourceEncodingDetector.getEncodingMemento(). (This method is called 689 times.)
Do you mean this is seen with thousands of CSS files, or ... what? I'm trying to think of how to reproduce so I can see if small improvements in code would lead to big improvemeents in overall time.
(In reply to comment #1) > Do you mean this is seen with thousands of CSS files, or ... what? There are 692 css files. It is almost same as the invocation count of CSSResourceEncodingDetector.getEncodingMemento(). (689 times.)
I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=157266 which relates to this problem. I am requesting to implement cache mechanism in ContentDescriptionManager.getDescriptionFor() method to avoid a lot of I/O access in Bug#157266. The method is called between ModelManagerImpl.createStructuredDocumentFor() and CSSResourceEncodingDetector.getEncodingMemento() in call stack. So, if Bug#157266 is resolved, it should affect to this, I think.
we'll investigate solutions for next round of fixes.
Untargeting to acknowledge no fix is in hand. But, will be investigated for 1.5.2. Setting priority to P4 to signify that it while it was enterted as 'critical' that is has been triaged and should not "stop ship", or anything. It is conceptually still a "P2", and will change it back once 1.5.1 ships.
Hot-bug request information 1. Affiliation: IBM 2. Release you want this bug to be fixed in: 1.5.2 3. Justify why this is a hot bug and why it needs to be fixed in that release: Performance.
I have looked at this, and do not really see anything that CSS Resource Encoding is doing wrong, or different. From what I've gathered, the "root" issue is that some information is not cached in content describer, as you've suggested in bug 157266. And that sounds like the right path to me. I am not aware of any solutions we could make in our code, and suspect you are not either, or else you would have already submitted a patch :) I think too this is not a simple regression, but a direct effect of adding the new functionality you requested for "CSS in JSPs"? (Right?) I would even be helpful if you have a test case you could attach. I've been meaning to create a 1000 CSS files, but haven't found the time yet. I suspect there's nothing we can do here, and will have to wait for 157266.
Hot bug removed, as not accepted as hot bug. Plus, since "critical" means "crashes, loss of data, etc" See https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#bug_severity I've change the severity to major.
I'm resolving this as works for me, as I don't think there is any bug here, per se, but related to 157266 and the CSS JSP support being added. Please let me know if you do see a fix we can make.
Closing as part of mass query to clean up old resolved bugs in untargetted milestones.
