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.
John
From: Lars Vogel <[email protected]>
To: Cross project issues <[email protected]>
Date: 12/11/2014 01:38 PM
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI
freezes when working with files
Sent by: [email protected]
I would guess that java.nio.file.Files.exists() [1] improves this access
performance. Do you see these freezes cause
by org.eclipse.core.resources.IResources or by directly using the Java
File API?
[1]
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#exists(java.nio.file.Path,%20java.nio.file.LinkOption...)
)
2014-12-10 14:53 GMT+01:00 Marcel Bruch <[email protected]>:
Hi,
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 [1] 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.
Best,
Marcel
[1]
http://stackoverflow.com/questions/20546676/webstart-winntfilesystem-getbooleanattributes-performance
--
Codetrails GmbH
The knowledge transfer company
Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-179-131-7721
http://www.codetrails.com/
Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
