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 169058 - 4312 ms in focusGained
Summary: 4312 ms in focusGained
Status: RESOLVED DUPLICATE of bug 169864
Alias: None
Product: editor
Classification: Unclassified
Component: Parsing & Indexing (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Vitezslav Stejskal
URL: http://statistics.netbeans.org/except...
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2009-07-23 15:49 UTC by Exceptions Reporter
Modified: 2009-08-07 13:17 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 153726

Attachments
nps snapshot (22.24 KB, bin/nps)
2009-07-23 15:50 UTC, Exceptions Reporter 		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-07-23 15:49:56 UTC 
Build: NetBeans IDE Dev (Build nbms-and-javadoc-3528-on-090714)
VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08
OS: Windows XP, 5.1, x86
Maximal alredy reported slowness was 24141 ms, average is 11150
Comment 1 Exceptions Reporter 2009-07-23 15:50:07 UTC 
Created attachment 85140 [details]
nps snapshot
Comment 2 Exceptions Reporter 2009-07-23 15:50:13 UTC 
This issue already has 7 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=153726
Comment 3 Jaroslav Tulach 2009-07-24 14:38:46 UTC 
Hard to identify who's fault this is. EditorRepository gets focusGained, calls RepositoryUpdater and it blocks in 
java.io via FileSystems. Reassigning to parsing API as it could easy reschedule its update to other thread than AWT, I 
guess.
Comment 4 Vitezslav Stejskal 2009-07-27 12:28:39 UTC 
Maybe we should simply defer all work associated with handling an event to the dedicated thread. Currently there are
some initial checks being done to make sure that we don't schedule high number of tasks that immediately finish. The
other way of dealing with this would be to cache more information about the roots themselves (eg. their FileObject).
This would minimize the number of URL <-> FileObject translations, which is what seems to be slow according to the
attached profiler snapshot.
Comment 5 Vitezslav Stejskal 2009-08-07 13:17:23 UTC 
Still the same problem with getOwningSourceRoot being slow. This should now be much better after fixing #169864.

*** This issue has been marked as a duplicate of 169864 ***