Bug 133479

Summary: Java builder reading contents 3 times on file save
Product: [Eclipse Project] JDT Reporter: Jerome Lanneluc <jerome_lanneluc>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: RESOLVED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: john.arthorne, laffrac
Version: 3.1Keywords: performance
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Jerome Lanneluc CLA 2006-03-28 04:28:09 EST
I20060328

Fron bug 133334, it appears that the Java builder is reading the content of the file that was just saved 3 times:
- once to get the charset
- once to diet parse
- once to parse method bodies

We might want to optimize this scenario.
Comment 1 Philipe Mulet CLA 2006-03-28 06:01:05 EST
We could optimize the diet/method body parse, but the charset read belongs to the platform.
Comment 2 Philipe Mulet CLA 2006-03-28 07:59:32 EST
John - is there something which could be improved at the platform level ? Ideally, the platform could cache a few contents (LRU), and it would address the situations described here. As for encoding read, there is nothing we can really do here without platform help.
Comment 3 John Arthorne CLA 2006-03-28 10:01:50 EST
We do cache the character set, so the third read to compute the character set will only happen once per source file.  When the charset is unknown, we only read the first two bytes of the file to compute the byte order mark (BOM), so this shouldn't be as expensive as a full read (although most of the cost is usually in opening the file).  I don't like the idea of caching file *contents* in memory at the platform level, because file contents can be arbitrarily large, and because there is no reliable way to compute if the cached contents are still valid (file timestamp granularity is not sufficient in many file systems).
Comment 4 Chris Laffra CLA 2006-03-28 10:13:19 EST
It will be almost impossible to beat the (very efficient) caching characteristics of operating systems such as Windows.
 
We have to find a higher place on the logical callstack to cache relevant information. JDT maintains a JavaModel, and that should be the entry point to consolidate the various phases in compilation/building. Currently, each phase goes to the same file to get a slightly different piece of information. 

We need a generalized query engine (think database) that can answer various questions on file system artifact, and hide the caching in there.
Comment 5 Philipe Mulet CLA 2006-04-10 10:59:15 EDT
no further action for 3.2
Comment 6 Eclipse Webmaster CLA 2009-08-30 02:41:42 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.