Community
Participate
Working Groups
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.
We could optimize the diet/method body parse, but the charset read belongs to the platform.
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.
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).
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.
no further action for 3.2
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
