Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 154324 - Do not initialize Profiler until it is first used
Do not initialize Profiler until it is first used
Product: profiler
Classification: Unclassified
Component: Base
All All
: P3 (vote)
: 7.1
Assigned To: J Bachorik
Depends on:
  Show dependency treegraph
Reported: 2008-12-02 10:29 UTC by Jaroslav Tulach
Modified: 2011-10-07 14:41 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT

Raw patch deferring initialization till an action is invoked (6.07 KB, patch)
2008-12-02 10:30 UTC, Jaroslav Tulach
Details | Diff
Modified JAR to let Alexander and Oleg measure potential gain of this change (3.61 MB, application/x-compressed)
2008-12-02 10:34 UTC, Jaroslav Tulach
Loaded Classes diff for 1st NetBeans startup (106.75 KB, text/plain)
2008-12-02 15:20 UTC, Alexander Kouznetsov
Loaded Classes diff for NetBeans startup with LimeWire (240.89 KB, text/plain)
2008-12-02 15:21 UTC, Alexander Kouznetsov

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2008-12-02 10:29:21 UTC
Currently ProfilerModule.restore() initializes the whole profiler infrastructure including various checks, spawning 
new threads, loading classes, etc. This was OK when profiler was just an add-on plugin, but since it is part of the 
standard distribution and because it is not used by majority of users (less than 30%, is my guess) and not all the 
time. It is desirable to defer such initialization till user clearly indicates an interest in the profiler itself.
Comment 1 Jaroslav Tulach 2008-12-02 10:30:54 UTC
Created attachment 74387 [details]
Raw patch deferring initialization till an action is invoked
Comment 2 Jaroslav Tulach 2008-12-02 10:34:31 UTC
Created attachment 74388 [details]
Modified JAR to let Alexander and Oleg measure potential gain of this change
Comment 3 Alexander Kouznetsov 2008-12-02 15:18:16 UTC
Whitelist violators report:

1st and 2nd startup:


Startup with LimeWire project:

Total: 8 class(es)

Total number of loaded classes is less by 52 in 1st and 2nd startup, by 58 in startup with LimeWire project.
Comment 4 Alexander Kouznetsov 2008-12-02 15:20:25 UTC
Created attachment 74423 [details]
Loaded Classes diff for 1st NetBeans startup
Comment 5 Alexander Kouznetsov 2008-12-02 15:21:56 UTC
Created attachment 74424 [details]
Loaded Classes diff for NetBeans startup with LimeWire
Comment 6 Alexander Kouznetsov 2008-12-02 15:30:34 UTC
Loaded Classes diff for 2nd NetBeans startup doesn't differ from Loaded Classes diff for 1st startup in the number of
loaded profiler classes.
Comment 7 J Bachorik 2009-04-27 15:20:33 UTC
Won't fix for 6.7

I have tested the patch but unfortunately the whole profiler infrastructure is initialized as soon as the "Profile" menu
is opened:

INFO [org.netbeans.lib.profiler.common.Profiler]: profiler is here org.netbeans.modules.profiler.NetBeansProfiler@3015b303
java.lang.Exception: stacktrace
        at org.netbeans.lib.profiler.common.Profiler.getDefault(
        at org.netbeans.modules.profiler.actions.ModifyProfilingAction.isEnabled(
        at org.openide.awt.Actions$MenuBridge.updateState(
        at org.openide.awt.Actions.connect(
        at org.openide.awt.Actions.connect(
        at org.openide.awt.Actions$MenuItem.<init>(
        at org.netbeans.modules.openide.awt.DefaultAWTBridge.createMenuPresenter(
        at org.openide.util.actions.CallableSystemAction.getMenuPresenter(
        at org.openide.awt.DynaMenuModel.loadSubmenu(
        at org.openide.awt.MenuBar$LazyMenu$MenuFolder.createInstance(
        at org.openide.loaders.FolderInstance.defaultProcessObjectsFinal(
        at org.openide.loaders.FolderInstance$
        at org.netbeans.modules.openide.loaders.AWTTask$
        at java.awt.event.InvocationEvent.dispatch(
        at java.awt.EventQueue.dispatchEvent(
        at org.netbeans.core.TimableEventQueue.dispatchEvent(
        at java.awt.EventDispatchThread.pumpOneEventForFilters(
        at java.awt.EventDispatchThread.pumpEventsForFilter(
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(
        at java.awt.EventDispatchThread.pumpEvents(
        at java.awt.EventDispatchThread.pumpEvents(
Comment 8 Jaroslav Tulach 2009-06-19 09:05:38 UTC
Test to verify profiler starts no threads on start is here: ergonomics#417c64acf417
Comment 9 Quality Engineering 2009-06-20 08:09:40 UTC
Integrated into 'main-golden', will be available in build *200906200201* on (upload may still be in progress)
User: Jaroslav Tulach <>
Log: #154324: Allowing profiler to start its test for now. As soon as #154324 is fixed, revert this commit
Comment 10 J Bachorik 2011-10-04 09:06:42 UTC
Profiler is being initialize lazily.

The test is updated to reflect the change
Comment 11 Quality Engineering 2011-10-07 14:41:05 UTC
Integrated into 'main-golden'
User: Jaroslav Bachorik <>
Log: #154324: Profiler thread is not being started prematurely

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo