Bug 218138 - IDE freezes because of slow file system access from EDT
IDE freezes because of slow file system access from EDT
Status: STARTED
Product: cnd
Classification: Unclassified
Component: Editor
7.2
All All
: P3 with 1 vote (vote)
: 7.3
Assigned To: Alexander Simon
issues@cnd
: PERFORMANCE
Depends on: 229671 229721 229730 229732 218203 218234 218236 218239 218708 218745 218746 218754 218760 218772 218774 218776 218785 218786 218790 218904 218908 218909 220294 221194 221200 225422 225427 225428 225453 229719
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-11 13:16 UTC by Egor Ushakov
Modified: 2014-02-06 13:23 UTC (History)
3 users (show)

See Also:
Issue Type: TASK
:


Attachments
File.* access from EDT report (120.95 KB, text/plain)
2013-05-14 12:52 UTC, Egor Ushakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Egor Ushakov 2012-09-11 13:16:04 UTC
Various users reported that IDE hangs while doing obvious things like entering first symbol in the file or switching files or focusing on the IDE from another application. There is an idea that this could be caused by "slow" filesystem, and that affects the IDE because it does many fs operations in EDT... I will try to create a test for it.
Comment 1 Egor Ushakov 2012-09-12 10:25:56 UTC
Most of these reports come from users working on NFS file system which can be very slow.
Comment 2 Egor Ushakov 2012-09-12 14:58:14 UTC
Current numbers of file system requests (File.isFile, File.exists, File.isDirectory, File.isHidden) from EDT:

new file open in the editor - 8-14
first symbol entered - 6
subsequent symbols entered - 1
file save - 15
opened file tab switch - 4
Comment 3 Egor Ushakov 2012-09-12 15:53:59 UTC
It may be beneficial to make a warning in the IDE log if we access file system
from EDT. Candidates may be:
FileObj.canWrite
Utilities.toURI
FileUtil.normalizePath
Comment 4 Egor Ushakov 2012-09-12 15:55:12 UTC
Easiest way to track such calls is to set breakpoints in File methods (exists, isDirectory, isFile) with the condition: javax.swing.SwingUtilities.isEventDispatchThread()
Comment 5 bht 2012-09-19 17:13:07 UTC
I suspect that excessive I/O can lead to CPU starvation. I have seen this on a system with sufficient memory where most I/O hits the disk cache. From that perspective, reducing I/O would be very rewarding.
Comment 6 Egor Ushakov 2012-09-20 09:39:12 UTC
thanks to the fix of #218203 now:
subsequent symbols entered - 0
Comment 7 Egor Ushakov 2012-10-31 15:48:05 UTC
there are many slowness reports in different parts of the IDE because of that, just the latest:
http://statistics.netbeans.org/analytics/detail.do?id=193321
http://statistics.netbeans.org/exceptions/detail.do?id=194345
http://statistics.netbeans.org/exceptions/detail.do?id=183632
All of them share the same root cause - accessing file system from EDT.
Comment 8 Egor Ushakov 2013-01-28 14:04:34 UTC
Thanks to everyone provided fixes!
Here is current statistics, it is much better now (less is better):
new file open in the editor  3-11 (was 8-14)
first symbol entered         2-7 (was 6)
subsequent symbols entered   0 (was 1)
file save                    0 (was 15)
opened file tab switch       0 (was 4)

I plan to analyze and file what's left soon.
Comment 9 Egor Ushakov 2013-05-14 12:34:01 UTC
We've done the analysis and found only one place where IDE reads project files in EDT, see bug 229719
Comment 10 Egor Ushakov 2013-05-14 12:41:48 UTC
ups, there is another one: bug 229721
Comment 11 Egor Ushakov 2013-05-14 12:52:29 UTC
Created attachment 134419 [details]
File.* access from EDT report
Comment 12 Alexander Simon 2014-02-06 13:23:49 UTC
this is umbrella task


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo