Community
Participate
Working Groups
When opening a class file editor on a class file that has no source, the source of the .class file or the source range are requested too many times.
I would expect this to be fast, similar to when there is source in which case we also access it many times. No plans to work on this for now but if you see a simple fix I'll accept a patch.
Even if fast, I think you ask the same question over and over again - I think I remember hundreds of times (note that the spec doesn't tell that this operation is free).
>I think I remember hundreds of times Do we? Do you have data because I don't think so. Maybe at your lowest end it seems 100x but if I call getA and getB and you count it twice, it's not the same. So, concrete data is welcome. This bug is rather vague.
If I find time I can do some measuring but now we're in 3.3 lock down I'm booked out.
I did a quick check ClassFile.getSource() is called just two times: once for the ClassFileDocumentProvider and once from the folding structure provider. ClassFile.getSourceRange() is called just four times: two times by the editor and once by some actions that need to set their enablement. Now, getBuffer() is hit MANY times and that's because the outline needs the categories for each member and the JDT Core code then goes and requests the buffer for each of those calls. There is nothing I can do about this. Moving to JDT Core to check whether calling getBuffer() is needed to get the categories of binary members that have no source.
Created attachment 69489 [details] Profiler output with instance count Interesting how many calls to the zip file(s) are needed to open sun.util.calendar.ZoneInfo.class
(In reply to comment #6) > Created an attachment (id=69489) [details] > Profiler output with instance count > > Interesting how many calls to the zip file(s) are needed to open > sun.util.calendar.ZoneInfo.class The profiler output shows that we iterate a list of 32000 zip entries. This is done in memory, we don't access the underlying file, so this has almost no cost. This is done the first time the source mapper for this jar is used. Opening another .class file with no source in the same jar won't go in this code.
>Opening another .class file with no source in the same jar won't go in this >code Yes, that's also what I saw.
The buffer is cached at the JDT/Core level. There is no eveidence that getting the buffer from the cache slows things down. Nothing more can be done.
