This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 268027 - Performance issue: FileUtil.normalizedRef cache is cleaned too frequently
Summary: Performance issue: FileUtil.normalizedRef cache is cleaned too frequently
Status: NEW
Alias: None
Product: ide
Classification: Unclassified
Component: Performance (show other bugs)
Version: Dev
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Tomas Hurka
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-14 16:11 UTC by NukemBy
Modified: 2016-09-14 16:11 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description NukemBy 2016-09-14 16:11:34 UTC
There is method FileUtil.normalizeFileCached() which is (I guess) supposed to workaround slowness of File.getCanonicalFile().
(More details here - https://netbeans.org/bugzilla/show_bug.cgi?id=65135)

However this cache appears to be cleaned too frequently, for each newly created instance of FileEvent, and negative effect of calls to File.getCanonicalFile() is very significant.

    public class FileEvent extends EventObject {

        public FileEvent(FileObject src, FileObject file, boolean expected, long time) {
            super(src);
            ...
            MIMESupport.freeCaches();
      -->   FileUtil.freeCaches();   <--
        }

        static void freeCaches() {
            normalizedRef.clear();
        }

With such implementation efficiency of cache is significantly reduced, because TTL of the entire cache is around 1 second - 'average' time between file events.

From the other side I see no much sense in cleaning this cache at all (except limiting the total size, what is not there) - some 'input path' will always be normalized to same 'output path'. The exception case may occur on Windows when casing of file name changes ('a'->'A') - this will result in 'wrong' cache entry, however it does not matter on windows - file path are 'case-insensitive' there and 'wrong' cached entry will will work when accessing file system.

However it may happen that caching should be implemented (additionally?) in another method - 

   package org.netbeans.modules.masterfs.filebasedfs;

   public final class FileBasedURLMapper extends URLMapper {
      public final FileObject[] getFileObjects(final URL url) {
        if (!"file".equals(url.getProtocol()))
            return null;
        ...
        try {
            file = FileUtil.normalizeFile(BaseUtilities.toFile(url.toURI()));
        } catch (URISyntaxException e) {


majority of the calls to FileUtil.normalizeFileCached() go through FileBasedURLMapper.getFileObjects(). File paths there are standard absolute path URLs - i.e. mapping between URL and corresponding FileObject is rather static. Additional point of caching on that layer is avoidance of construction of new instances of of FileObject (more performance gain).