The IResource/IWorkspace API is backed
by a completely in-memory skeleton of your file system structure. So any
time you can query the resource model instead of the file system, you will
see orders of magnitude performance improvement over direct java.io.File
access. The IResource API (and EFS) encourage a batch-style interaction
for the rare thing that is not in memory. For example IResource#getResourceAttributes
or IFileStore#fetchInfo returns a struct of all the attributes in
a single native call, which is vastly more efficient than doing many calls
such as if (file.exists() && file.isFile() && file.canRead())
For the IResource API and much of the
rest of the platform API, the best indicator is whether there is an IProgressMonitor
in the API method. If the method takes a progress monitor, you probably
don't want to call it from the UI thread. If there is no progress monitor,
then for the most part you are ok. There are a few embarrassing exceptions
to this (e.g.,, Job#join), but it's a useful rule of thumb.
Lars Vogel <lars.vogel@xxxxxxxxx>
Cross project issues
12/11/2014 01:38 PM
Observation: Frequent UI freezes when working with files
I would guess that java.nio.file.Files.exists()  improves
this access performance. Do you see these freezes cause by org.eclipse.core.resources.IResources
or by directly using the Java File API?
I just want to share an insight I got from reviewing several ui freezes.
One common cause for UI freezes are operations that touch the filesystem.
For instance, File.isFile, File.lastModified, or WinNTFileSystem.getBooleanAttributes
seem to be very expensive. From what I read on the internet it seems that
some of these methods (e.g. getAttributes) may even take up to several
seconds to return on windows systems.
This has been discussed elsewhere in the internet  and seems to be a
long-standing issue in Java.
With this mail Iâd like to make you aware of this (in case you did not
know this before) and would like to encourage you to actually not execute
file operations in the ui thread. We may also consider doing some kind
of caching but such a discussion would by far be over my knowledge, and
thus, should be left to discuss with the platform team.
For now, I think we would benefit very much if every project that accesses
files/resources would review their code and think about refactoring some
part of the FileSystem work (even if itâs only checking a fileâs attributes)
into background processes.