This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 170813 - Too much I/O activity from a org.nbheaven.sqe..OpenTopComponentListener
Summary: Too much I/O activity from a org.nbheaven.sqe..OpenTopComponentListener
Status: RESOLVED FIXED
Alias: None
Product: third-party
Classification: Unclassified
Component: sqe tools (show other bugs)
Version: 6.x
Hardware: All Windows XP
: P2 blocker (vote)
Assignee: sreimers
URL: http://statistics.netbeans.org/except...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-24 15:18 UTC by Exceptions Reporter
Modified: 2010-01-25 08:34 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 156660

Attachments
nps snapshot (18.81 KB, bin/nps)
2009-08-24 15:18 UTC, Exceptions Reporter 		Details
nps snapshot (256.00 KB, application/nps)
2010-01-22 04:55 UTC, bsbc99 		Details
nps snapshot (256.00 KB, application/nps)
2010-01-25 08:34 UTC, bsbc99 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Exceptions Reporter 2009-08-24 15:18:55 UTC 
Build: NetBeans IDE Dev (Build nbms-and-javadoc-3789-on-090821)
VM: Java HotSpot(TM) Client VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01
OS: Windows XP, 5.1, x86
Maximum slowness yet reported was 66658 ms, average is 66658
Comment 1 Exceptions Reporter 2009-08-24 15:18:59 UTC 
Created attachment 86567 [details]
nps snapshot
Comment 2 Milan Kubec 2009-09-08 09:30:20 UTC 
Reassigning to performance for re-evaluation, I think that the problem is in unusually long time spent in filesystem
operations.
Comment 3 Pavel Flaska 2009-09-08 14:41:36 UTC 
Slowness of native NTFS call (WinNTFileSystem.canonicalize0). Reported many times, but there it is still not obvious why some of filesystem is so slow (broken 
links?, corrupted fs?)
Comment 4 Jaroslav Tulach 2009-09-11 16:14:31 UTC 
I think I learned how to read these snapshots. Look at the # of invocations in 
http://statistics.netbeans.org/exceptions/exception.do?id=248491

There is one call to: RegistryImpl.topComponentOpened
then there are two calls to: PropertyChangeSupport.firePropertyChange
which end up in one call all: org.nbheaven.sqe.codedefects.core.api.install.OpenTopComponentListener

From here the number of calls is growing, at the end it reaches 100 calls to File.canonicalize(). At least 100, 
possibly few thousands as we do sampling and the number of calls is informative and always just bottom boundary. So 
the problem is not that one call to getBooleanAttribute would be slow, the problem is that 
org.nbheaven.sqe.codedefects.core.api.install.OpenTopComponentListener does too much I/O activity in AWT thread.

The question is where the nbheaven.sqe comes from... CCing Jirka and Marian.
Comment 5 sreimers 2009-09-11 16:44:40 UTC 
sqe - that would be me
Comment 6 sreimers 2009-09-11 17:47:20 UTC 
Ok. Seems you are absolutely correct here. Will try to fix this in SQE. Thanks for spotting. 

Should this be reassigner to 3rd party / sqe?
Comment 7 Jaroslav Tulach 2009-09-13 06:47:05 UTC 
Thanks Sven.
Comment 8 Jesse Glick 2009-09-29 00:43:33 UTC 
Doing more work in a BG thread: sqe #55a84cc8f48e
Comment 9 bsbc99 2010-01-22 04:55:17 UTC 
Created attachment 93483 [details]
nps snapshot
Comment 10 bsbc99 2010-01-25 08:34:41 UTC 
Created attachment 93530 [details]
nps snapshot