harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Lee <littlee1...@gmail.com>
Subject Re: interesting commentary via android bug report
Date Wed, 13 Jan 2010 06:14:25 GMT
On Wed, Jan 13, 2010 at 1:49 PM, Jesse Wilson <jessewilson@google.com> wrote:
> On Tue, Jan 12, 2010 at 7:47 PM, Charles Lee <littlee1032@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

Mime
View raw message