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 153383 - Regression: profiler classes are loaded during NetBeans startup with LimeWire project
Summary: Regression: profiler classes are loaded during NetBeans startup with LimeWire...
Status: RESOLVED FIXED
Alias: None
Product: profiler
Classification: Unclassified
Component: Base (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: J Bachorik
URL: http://wiki.netbeans.org/FitnessViaWh...
Keywords: PERFORMANCE, REGRESSION, TEST
Depends on:
Blocks:
 
Reported: 2008-11-18 13:24 UTC by Alexander Kouznetsov
Modified: 2011-10-01 14:06 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Stacktraces (42.39 KB, text/plain)
2008-11-18 13:26 UTC, Alexander Kouznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Kouznetsov 2008-11-18 13:24:21 UTC
Performance test reports that there is NetBeans startup regression caused by the loading of the following classes:

org.netbeans.modules.profiler.AbstractProjectTypeProfiler
org.netbeans.modules.profiler.RerunSupport
org.netbeans.modules.profiler.freeform.FreeFormProjectTypeProfiler
org.netbeans.modules.profiler.j2ee.J2EEProjectTypeProfiler
org.netbeans.modules.profiler.j2se.J2SEProjectTypeProfiler
org.netbeans.modules.profiler.nbmodule.NbModuleProjectTypeProfiler
org.netbeans.modules.profiler.utils.ProjectUtilities

Please don't load these classes unless they're really necessary.

Regression occurred between 081105 and 081117.

Comment from jtulach: 
Report a bug against profiler. They should not initialize all profile types 
when trying to find out if profiling is supported:
          
org.netbeans.modules.profiler.utils.ProjectUtilities.getAllProjectTypeProfilers(ProjectUtilities.java:176) 
org.netbeans.modules.profiler.utils.ProjectUtilities.getProjectTypeProfiler(ProjectUtilities.java:513)          
org.netbeans.modules.profiler.actions.AntActions.isProjectTypeSupported(AntActions.java:741)
org.netbeans.modules.profiler.actions.AntActions$1.enable(AntActions.java:134) 
org.netbeans.modules.project.ui.actions.MainProjectAction.refreshView(MainProjectAction.java:206)          
org.netbeans.modules.project.ui.actions.MainProjectAction.<init>org.netbeans.modules.project.ui.actions.MainProjectAction.<init>org.netbeans.modules.project.ui.actions.Actions.mainProjectSensitiveAction(Actions.java:145)
org.netbeans.spi.project.ui.support.MainProjectSensitiveActions.mainProjectSensitiveAction(MainProjectSensitiveActions.java:87)
Comment 1 Alexander Kouznetsov 2008-11-18 13:26:06 UTC
Created attachment 73865 [details]
Stacktraces
Comment 2 J Bachorik 2008-11-18 20:51:57 UTC
First of all, I don't think this is a regression (thus lowering to P3). The functionality causing the violation has been
in the profiler for ages. If you think otherwise, please provide the profiler version this regression is against.
The second part is more complicated - what else should be used to implement a project-type dependent functionality? If I
use LookupProvider I end up with issue like #152984. If I do it my own custom way (polling all registered profiler types
whether they can work with a certain project type) I'm getting this issue filed. This really confuses me - what am I
supposed to do? Not to write a project type specific functionality at all?
Plz, advice ...
Comment 3 Alexander Kouznetsov 2008-11-19 15:02:37 UTC
> Regression occurred between 081105 and 081117.

Let's wait for advice from jtulach.
Comment 4 J Bachorik 2008-11-20 17:22:08 UTC
Given that there was no activity in the profiler code base during the dates mentioned I really don't think it's caused
by profiler. The functionality has been there since the first version so it must be something else that had changed and
caused this particular functionality to be invoked.
QA, plz, try to locate the exact revision which caused the regression in results. 

However, I'm not going to fix this issue till issue #152984 is resolved - solving this would just bring me another P2
regression so it's plainly a waste of time.
Comment 5 Alexander Kouznetsov 2008-11-25 10:08:11 UTC
org.netbeans.modules.profiler.RerunSupport was not loaded with 081125
Comment 6 Jaroslav Tulach 2008-12-03 13:34:39 UTC
Alexander asked me to express my advices: The preferred way is to register the ProjectTypeProfiler into appropriate 
project type lookup. This would work in much better (more lazy) way, especially with connection to issue 150194. 
Untill the issue 150194 is fixed, let's keep this issue open and let's hope we will have a chance to fix it for 7.0.
Comment 7 J Bachorik 2009-03-20 16:00:53 UTC
Lowering the priority as the offending class RerunSupport has mysteriously disappear. It's not even possible to get
history information from mercurial (try eg.
http://hg.netbeans.org/main/log/5bdcbcceb230/profiler/src/org/netbeans/modules/profiler/RerunSupport.java). Given this,
it definitely can not be loaded at the IDE startup.

As for the rest of the classes mentioned here - resolving this issue would require a rewrite of the profiler IDE
integration and in current situation it won't happen soon.
Comment 8 Tomas Hurka 2009-04-08 12:52:50 UTC
Milestone cleanup: future->next
Comment 9 J Bachorik 2011-09-28 13:59:05 UTC
ProjectTypeProfiler has been replaced by per-project registration of various profiler services. Further reduction of the profiler classes loaded at startup has been done in http://hg.netbeans.org/profiler-main/rev/29cb4f37f1aa

Closing the issue.
Comment 10 Quality Engineering 2011-10-01 14:06:42 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/29cb4f37f1aa
User: Jaroslav Bachorik <yardus@netbeans.org>
Log: Reducing the number of profiler classes loaded at startup. Related to #153383,#201356,#201357.