Summary: | [perf] Excessive File.isFile calls for clients of JavaModel.getTarget(...) | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dan Kehn <kehn> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | gmendel, karasiuk, Mike_Wilson, richkulp, Tod_Creasey |
Version: | 3.1 | Keywords: | performance |
Target Milestone: | 3.1 M7 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: | |||
Bug Depends on: | |||
Bug Blocks: | 61944 | ||
Attachments: |
Description
Dan Kehn
2005-01-26 14:01:44 EST
Created attachment 17479 [details]
JavaModel.isFile and getFile convenience methods
Created attachment 17480 [details]
JavaProject use JavaModel.isFile (search on dbk)
Created attachment 17481 [details]
PackageFragmentRoot use JavaModel.getFile (search on dbk)
Created attachment 17482 [details]
JavaCore use JavaModel.getFile (search on dbk)
Created attachment 17483 [details]
ClasspathEntry use JavaModel.getFile (search on dbk)
The caching approach is interesting, though a cache need to be updated to be useful (i.e. if a file becomes unavailable, the cache must not hide this fact). Jerome - can you please look at it ? Feels like a good perf issue. Thanks Philippe, all improvements are welcome. The issue of keeping the cache in sync already exists for the current JavaModel.existingExternalFiles variable. I added clearing the new JavaModel.existingExternalConfirmedFiles to the flushExternalFileCache() method assuming this would cover it. FYI: With this and all the other I/O optimizations in place denoted in bug 61944, the current score for a warm editor open is JDT 164 I/O events versus JVE 338. That's probably as good as we can do without prefetching the JVE model (similar to your persisted JavaModel cache). Back to CPU usage analysis... Adding my name to the cc list as we are now tracking performance issues more closely. Please remove the performance keyword if this is not a performance bug. Thanks Tod, it is and remains a performance issue (small but measurable). Pls investigate if anything realistic can be made. Re: comment#7. No the external file cache is not meant to be updated frequently, and hooking into it will not allow you keep up with normal development. It is only meant to cache immutable files (binaries). How long does it take to open an editor, and what percentage of that time is made up by these calls? Fixed and released in HEAD. Thanks Dan for the patch which looks so good that I've released as this. All JDT/Core and JDT/UI pass with it. I'll add specific performance test cases if time permit. Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD (the code shows the additions described in the bug - no performance test run though). |