I've always been wondering why even with the native FileWatcher, the
synchronization (manual and on frame re-activation) is so slow. I learned to
live with it, but now I found out that if I select all root directories in the
project view and invoke "Synchronize selected files" action from the context
menu, the action finishes in no time (btw: the warning that this may take a long
time is simply wrong - at least compared to the time it takes when invoking the
Synchronize-action from the toolbar, which doesn't even show a warning).
So I had a look at the CPU snapshots and found that all the time is spent inside
java.io.File.lastModified() - isn't it the FileWatcher's job to avoid such
explicit up-to-date checks?
All those calls come from JarFileSystemImpl.a(JarFileInfo, boolean, boolean), so
this seems to be related to refreshing JAR files, not regular files. However, if
a JAR file itself doesn't change, I think it's safe to assume that the files it
contains haven't changed as well.
With that observation I think there's a lot of room for optimization - unless I
got something wrong. In that case I'd be interested in understanding what this
is: it would make it easier to accept the slowness ;)