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 170949 - 51s in ActiveConfigAction
Summary: 51s in ActiveConfigAction
Status: RESOLVED DUPLICATE of bug 175348
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Projects UI (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker (vote)
Assignee: Milan Kubec
URL: http://statistics.netbeans.org/except...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-26 17:18 UTC by Vladimir Voskresensky
Modified: 2010-09-23 12:55 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter: 156980

Attachments
nps snapshot (18.88 KB, bin/nps)
2009-08-26 17:19 UTC, Vladimir Voskresensky 		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 Vladimir Voskresensky 2009-08-26 17:19:00 UTC 
Build: NetBeans IDE Dev (Build 090826)
VM: Java HotSpot(TM) Client VM, 11.3-b02, Java(TM) SE Runtime Environment, 1.6.0_13-b03
OS: Linux, 2.6.27-7-generic, i386

User Comments:
vv159170: started IDE previously closed with 6 projects


Maximum slowness yet reported was 51346 ms, average is 51346
Comment 1 Vladimir Voskresensky 2009-08-26 17:19:04 UTC 
Created attachment 86704 [details]
nps snapshot
Comment 2 Milan Kubec 2009-09-08 13:50:28 UTC 
IMO most of the time is spent in File operation. Please re-evaluate. Thanks.
Comment 3 Jaroslav Tulach 2009-09-08 14:34:24 UTC 
What exactly you want us to re-evaluate? AWT is blocked by ActiveConfigAction for 51s. It blocks and waits for some 
background activity. It shall not block for such a long time.

Thinking about it, 51s is a lot more than UI guidelines allow. Making P2:
http://performance.netbeans.org/responsiveness/whatisresponsiveness.html
Comment 4 Milan Kubec 2009-09-08 15:04:35 UTC 
Thanks for valuable advice. Setting priority back to P3 since 42s of those 51s is spent in File.lastModified().

Reassigning to apisupport for further evaluation.
Comment 5 Jesse Glick 2009-09-09 17:52:51 UTC 
Usual issue of being too slow to load module list.

*** This issue has been marked as a duplicate of 169040 ***
Comment 6 rmichalsky 2009-09-24 14:50:59 UTC 
Although it is blocked by loading module universe, this won't get resolved with fix of issue #169040. Here's the
probable setup according to the snapshot:

1) 2 projects are being open during startup: one project with some configurations (e.g. J2SE) and an apisupport project
2) user does something (not sure what) which triggers ActiveConfigAction.refreshView() and PM.findProject in EQ, which
probably gets blocked by loading NBM project.

Strange thing is that both threads need only read lock on PM.mutex() and I don't see anything else that would block
them. Possible solution would IMHO be to refresh view in background or somehow break the notification chain in AWT
thread. Can't really be solved by any speedup of module list loading as it is blocked for 42 s in native lastModified()
method.
Comment 7 Milan Kubec 2009-09-25 11:30:14 UTC 
I don't want to juggle with threads when refreshing ActiveConfigAction just because of this one single report that is
moreover suspicious because of 42 sec. spent in simple native IO call. Closing the issue until there are more similar
reports of this performance problem.
Comment 8 Jesse Glick 2010-09-23 12:55:46 UTC 

*** This bug has been marked as a duplicate of bug 175348 ***