Community
Participate
Working Groups
ContentDescriptionManager.getDescriptionFor(File, ResourceInfo) is called by our validators/builders. Because I use project specific content type settings, readDescription(File) method is called everytime in getDescriptionFor() method. This means I/O access happens everytime. Our method call takes about 5 seconds totally, and getDescriptionFor() method consumes 38 percent in it. On the other hand, I think you have already had cache mechanism in getDescriptionFor() method for global/workspace-wide content type settings. Could you please implement similar cache mechanism for project specific setting? Since the method is called many time, if you implement the cache mechanism, it should improve the performance.
What is being attempted to be queried about the description/content type? Is it (only) charset? (If so, I think there's already caching for that, at least through the normal, public methods ... at least up to about 500 or 1000 files, or similar). If, on the other hand, its some other arbitrary 'property' of IContentDescription, then ... perhaps that's the key info needed to fix this. BTW, this doesn't happen to be for CSS in JSP's, does it? (where the current approach is to look for specific filename? If that's the case .. then, that reminds me I never did open a feature request for being able to arbitrarily, programatically set the a contentType of a specifc resource :)
I thought whether or not that content type/description itself could be cached. That's for CSS in JSP's. Since project specific content type is enabled in our case, ProjectContentTypes.usesContentTypePreferences(filename) method always returns true. And then, readDescription() method seems to be called for any type of files. I saw a comment, "caching for project containing project specific settings is not supported". If possible, if the caching is implemented, I thought the performance is improved.
I compared 2 projects. (They have different files.) Project A (project specific content type settings is used) = no cache Project B (no project specific content type setting)= with cache 1st build [Project A] getDescriptionFor() method is called 2,984 times and it takes 7,637 msec. [Project B] getDescriptionFor() method is called 5,339 times, but it takes 2,058 msec, because readDescription() is called only 851 times. It seems cache is effective for multiple builders. 2nd build [Project A] getDescriptionFor() takes 5,657 msec. [Project B] getDescriptionFor() takes 107 msec
changed to critical.
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 understand that this is important to you, but "critical" in this bug system means "crashes, loss of data, severe memory leak". I am increasing priority, but classifying as an enhancement.
Also, 1.5.2 is a Web Tools release, and "hotbug request" is a Web Tools Project convention. The next platform release is 3.2.2 at the end of February 2007.
Could the target for this be set please.
There is no planned target for this request... "LATER" is the most accurate assessment at the moment.
(In reply to comment #9) > There is no planned target for this request... "LATER" is the most accurate > assessment at the moment. Any target decided for this bug?
There is no planned target for this request. Patches welcome.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
