On Wed, Jan 13, 2010 at 1:49 PM, Jesse Wilson <jessewil...@google.com> wrote: > On Tue, Jan 12, 2010 at 7:47 PM, Charles Lee <littlee1...@gmail.com> wrote: > >> What's the reason of bad idea? limited memory? >> > > A cache that cannot be cleared is a disservice to users. It's an error in > our implementation (and the RI!) to assume that an application requesting > the canonical path two times wants to receive the same result. If the > application wants the same value, why doesn't the *application* cache the > result?! > > If we want to make Harmony faster, there are better ways to do so. The > simpler optimization is to streamline the code that looks up the canonical > path *the first time*. Reducing the number of times we cross a JNI boundary > is one of many opportunities here. >
IIRC, the reason we add the cache to the File is because RI seems much faster than harmony. And reduce the number of times we cross a JNI boundary improve the performance indeed, but still has a lot to improve comparing with RI. There is still a concern here: people who is using RI will not cache the result in their application because getCanonicalPath() is fast in RI. > > What's the reason of bad implement? Anyone knows? >> > > The canonical path cache code we shipped with Android 2.0 occasionally > caused applications to crash with a NoSuchElementException. > Yeah. It is a bug which has been fixed recently (HARMONY-6414). It seems too late :-( -- Yours sincerely, Charles Lee
