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 40420 - Startup time regression caused by 500x slower o.o.util.actions.CallbackSystemAction.findGlobalContextAction()
Summary: Startup time regression caused by 500x slower o.o.util.actions.CallbackSystem...
Status: VERIFIED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: Actions (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P2 blocker (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: PERFORMANCE, REGRESSION
Depends on:
Blocks: 36556
  Show dependency tree
 
Reported: 2004-02-24 14:35 UTC by Antonin Nebuzelsky
Modified: 2008-12-22 19:38 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Snapshot of jprofiler window with the method in NB351 (115.18 KB, image/png)
2004-02-24 14:41 UTC, Antonin Nebuzelsky 		Details
Snapshot of jprofiler window with the method in trunk (114.92 KB, image/png)
2004-02-24 14:41 UTC, Antonin Nebuzelsky 		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 Antonin Nebuzelsky 2004-02-24 14:35:37 UTC 
There is a big execution time regression of
findGlobalContextAction() method. Profiler shows
me 500x worse times for the current implementation
in trunk in comparison to NB351. This participates
on the startup time regression we have.

The method was slowed down perhaps with the
version 1.30.
Comment 1 Antonin Nebuzelsky 2004-02-24 14:41:02 UTC 
Created attachment 13605 [details]
Snapshot of jprofiler window with the method in NB351
Comment 2 Antonin Nebuzelsky 2004-02-24 14:41:51 UTC 
Created attachment 13606 [details]
Snapshot of jprofiler window with the method in trunk
Comment 3 Antonin Nebuzelsky 2004-02-24 14:49:35 UTC 
The cause is in the initialization of
CallbackSystemAction$GlobalManager and down to
o.o.windows.TopComponent.getRegistry... and down to WindowManager
initialization... :-)
Comment 4 Jaroslav Tulach 2004-02-24 15:05:30 UTC 
There is a change, that is true, but the TopComponent registry would
have to be initialized anyway, even in 3.5. The time just moved from
one place to another, imho. I cannot verify this, as the screenshot
does not show what actually is happening under
GlobalManager.getDefault(), but I belive it is not more then what
would happen in another place in 35 anyway.
Comment 5 Antonin Nebuzelsky 2004-02-24 15:32:51 UTC 
Correct. Anyway tracking it down I realized that WindowManager
initialization now takes four times longer than in NB351. But it's a
completely different story... ;-)