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
