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 63766 - JMManager.waitScanFinished does not perform well
Summary: JMManager.waitScanFinished does not perform well
Status: RESOLVED WONTFIX
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 5.x
Hardware: All All
: P3 blocker (vote)
Assignee: issues@java
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2005-09-07 12:16 UTC by _ rkubacki
Modified: 2008-02-25 16:16 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
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 _ rkubacki 2005-09-07 12:16:31 UTC 
I am surprised that my sampling profiler notices that the method is executed. It
 should just wait for finished scanning and once it is notified it can return.
Unfortunately it waits actively and awakes every 100ms performs some jobs and
sleeps again. I see 400-500 iterations of the loop before my IDE gets started on
my Solaris (total startup time is ~55s and can be even worse for cold start).
Comment 1 _ rkubacki 2005-09-07 12:35:28 UTC 
Currently there are at least four usages that queries periodicaly during startup
whether scanning is done: annotations refreshing, fold updating, something
related to nodes, navigator.
Comment 2 Jan Becicka 2005-09-23 13:35:52 UTC 
Lets' try to measure affect of this bug. Please try to measure startup time and
compare it with startup time of patched ide.
Patch is not a real fix, it just minimize number of iterations.
Comment 3 Jan Becicka 2005-09-23 14:38:02 UTC 
OK. Ignore my last comment. We discussed it face by face with Radim.
Comment 4 _ rkubacki 2005-09-23 15:08:43 UTC 
Re impact: Although the duration of each loop body is neglectible my profiler
that samples every 1ms notices almost each iteration. It usualy shows that the
state is either 'Wiat CPU' or 'Other wait' and only rarely it is 'User CPU'.
Reported time in user CPU state is >0.1% ot total startup time with this
sampling. Given that it is sampling and there should be other overhead with
context switching it seems that the impact can be much higher. OTOH the startup
sequence is really long here because it is not a fast machine and it is
profiling (even fast machine can suffer from active waiting if you have a
complex setup).

It might be interesting to measure this with dtrace.
Comment 5 Petr Hrebejk 2006-11-20 16:50:21 UTC 
Moving to different subcomponent. With respect to the latest changes in java
infrastructure will likely not be fixed.
Comment 6 _ tboudreau 2007-05-23 22:43:54 UTC 
Any reason this and other MDR related issues are not closed?  It's a little hard
to get a picture of what things are really needing fixing and not when doing a
query against the Java module (I'm trying to submit less duplicate bugs).
Comment 7 Quality Engineering 2007-09-20 11:54:14 UTC 
Reorganization of java component
Comment 8 Jan Becicka 2008-02-25 16:16:48 UTC 
This issue is not valid in current builds any more. Java support was completely
redesigned in 6.0 time frame. Please use NetBeans 6.0 and later.