Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
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 lars.vo...@gmail.com
To: Cross project issues cross-project-issues-dev@eclipse.org
Date: 12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI
freezes when working with files
Sent by:cross-project-issues-dev-boun...@eclipse.org
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 marcel.br...@codetrails.com:
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
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
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
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
Hi,
The most significant UI bloopers of the sort that Marcel mentioned I have seen
in dialogs which validate input fields to actually be a file on every keystroke.
This really hurts if the path you’re trying to enter is a Windows UNC path
(\\myserver\myshare\path\to\file.cfile:///\\myserver\myshare\path\to\file.c)
and you make the beginner’s mistake of just starting to type … trying to
validate \\mfile:///\\m and then \\myfile:///\\my and then
\\mysfile:///\\mys will cost an average time of 2-5 seconds per keystroke
which is really painful. The workaround is typing your path in an external
editor and then “pasting” in one shot, or typing a relative path first (which
is obviously no file) and then inserting the \\ at the beginning as your last
action.
I would love to see some sort of common infrastructure, which can be applied on
arbitrary folders (not just IResource) and would return answers like isFile()
asynchronously via callback in order to validate or invalidate dialogs … of
course any new keystroke would need to cancel any pending asynchronous
request(s) in order to just validate the new request.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, December 11, 2014 7:54 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when
working with files
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 lars.vo...@gmail.commailto:lars.vo...@gmail.com
To:Cross project issues
cross-project-issues-dev@eclipse.orgmailto:cross-project-issues-dev@eclipse.org
Date:12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI freezes
when working with files
Sent by:
cross-project-issues-dev-boun...@eclipse.orgmailto:cross-project-issues-dev-boun...@eclipse.org
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
marcel.br...@codetrails.commailto:marcel.br...@codetrails.com:
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-7092tel:%2B49-6151-276-7092
Mobile: +49-179-131-7721tel:%2B49-179-131-7721
http
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
We have something in Sapphire that would be applicable.
http://git.eclipse.org/c/sapphire/org.eclipse.sapphire.git/tree/plugins/org.eclipse.sapphire.ui/src/org/eclipse/sapphire/ui/DelayedTasksExecutor.java
In the text change listener, we schedule a task to update the model (an
operation that can be expensive). The executor only runs the tasks once things
have been quiet for a certain time (no new tasks). This allows us to provide
“immediate” on-change feedback without making the UI appear sluggish to the
user while they are entering data.
Thanks,
- Konstantin
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of Oberhuber,
Martin
Sent: Thursday, December 11, 2014 12:04 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when
working with files
Hi,
The most significant UI bloopers of the sort that Marcel mentioned I have seen
in dialogs which validate input fields to actually be a file on every keystroke.
This really hurts if the path you’re trying to enter is a Windows UNC path
(\\myserver\myshare\path\to\file.c file:///\\myserver\myshare\path\to\file.c
) and you make the beginner’s mistake of just starting to type … trying to
validate \\m file:///\\m and then \\my file:///\\my and then \\mys
file:///\\mys will cost an average time of 2-5 seconds per keystroke which
is really painful. The workaround is typing your path in an external editor and
then “pasting” in one shot, or typing a relative path first (which is obviously
no file) and then inserting the \\ at the beginning as your last action.
I would love to see some sort of common infrastructure, which can be applied on
arbitrary folders (not just IResource) and would return answers like isFile()
asynchronously via callback in order to validate or invalidate dialogs … of
course any new keystroke would need to cancel any pending asynchronous
request(s) in order to just validate the new request.
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: cross-project-issues-dev-boun...@eclipse.org
[mailto:cross-project-issues-dev-boun...@eclipse.org] On Behalf Of John Arthorne
Sent: Thursday, December 11, 2014 7:54 PM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Observation: Frequent UI freezes when
working with files
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 lars.vo...@gmail.com
To:Cross project issues cross-project-issues-dev@eclipse.org
Date:12/11/2014 01:38 PM
Subject:Re: [cross-project-issues-dev] Observation: Frequent UI freezes
when working with files
Sent by:cross-project-issues-dev-boun...@eclipse.org
_
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 marcel.br...@codetrails.com:
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
Re: [cross-project-issues-dev] Observation: Frequent UI freezes when working with files
Marcel, This seems to be very low level detail. Do you know or can you see if this relates to some higher level operation being performed from within in the UI thread which shouldn't? -Gunnar Am 10.12.2014 um 14:53 schrieb Marcel Bruch marcel.br...@codetrails.com: 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 cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev -- Gunnar Wagenknecht gun...@wagenknecht.org ___ cross-project-issues-dev mailing list cross-project-issues-dev@eclipse.org 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] Observation: Frequent UI freezes when working with files
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 cross-project-issues-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
