harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] add cache for file's canonical path
Date Wed, 01 Jul 2009 15:38:14 GMT
Regis wrote:
> Tim Ellison wrote:
>> Regis wrote:
>>> Recently I'm trying to optimize implementation of java.File,
>>
>> Cool.
>>
>>> and find File.getCanonicalPath is very time cost and is heavily used
>>> by checking file permission. But in the most of cases, the canonical
>>> path is never change, so I think it's better to cache them to avoid
>>> calculate every time. And I found RI also has cache:
>>> File.getCanonicalPath doesn't reflect change in file system
>>> real-time.
>>
>> Hmm, sounds risky to me -- at least liable to create unpredictable
>> behavior.
> 
> The file's canonical path changed rarely, on Linux, only symbol link in
> the path changed, can cause canonical path change; and on Windows, only
> when path contains short name, the canonical path can be changed.
> Maybe we can choose to not cache paths which are relatively "volatile",
> such as path contained short name on Windows?
> 
>>
>>> I have created a JIRA HARMONY-6200 for this, and attach a simple cache
>>> implementation for file's canonical path, someone interested in this may
>>> can help to review it.
>>>
>>> The cache has fixed size, when it's full oldest element would be remove,
>>> and elements would be expired in 10 minutes, that mean if the element
>>> stay in cache more than 10 minutes, it's not validate and will be
>>> removed.
>>
>> Ten minutes seems like a very long time.  I would have thought that
>> having a cache that expires in a relatively short time (since that file
>> path was last accessed) would be sufficient.
> 
> So how about one minute?
> And I prefer to define expiring time as time since that file path added
> to the cache, because there may be some hot paths accessed frequently,
> if expiring time is count from last accessed, they may stay in cache too
> long and have no chance to update from file system.
> 
>>
>>> It's a initial implementation, I believe there are still many places can
>>> be improved, any comments and suggestions are welcome.
>>
>> My initial thought is that it would be preferable to have the OS tell
>> you when a file path changes so you can invalidate the cache, but there
>> may not be enough info to be able to do that...

Now that M10 is out the way, it may be time to revisit this idea.

WDYT?

Tim

Mime
View raw message