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.
070709. I opened the nbbuild freeform project (_not_ its required projects). The project opening dialog stayed open for quite a long time, with heavy CPU activity. This surprised me since the project itself is small and ought to open quite quickly - which until today it always has. Thread dumps showed that ProfilingPointsManager.processOpenedProjectsChanged was doing something with the subproject list. Please do not do this. I was not even using the profiler in this session at all, and I do not wish for project opening to be many times slower because of some profiler feature.
Created attachment 44856 [details] Representative excerpt from a thread dump
We need to get a list of all subprojects for each opened project to find all defined profiling points, display them in Profiling Points window and eventually use them for profiling. If SubprojectProvider.getSubprojects() is too slow and shouldn't be used, then this should probably be mentioned in API documentation. I can't see anything we can change at profiler side. Processing subprojects moved from EDT to RequestProcessor, Opening Project dialog is no more blocked. Fixed for Beta1.
But I'm not even using the profiler! Can't you simply defer all this work until the user actually tries to profile something?
Profiling points are shown in editor as annotations the same way as breakpoints no matter if you use the profiler/debugger or not. That's why opened projects & their subprojects have to be processed everytime to load the profiling points and display them when necessary.
I can understand loading profiling points from open projects to display editor annotations, but why subprojects? In this example, I might have had some points in nbbuild/antsrc (I did not, in fact), but why does it matter what its subprojects were? The only subproject in which I actually have any profiling points is java/project - 1 out of ~500 - and that was not open, nor was I opening any files from it.
During profiling session profiling points defined for profiled project and its subprojects are processed, that's why they should also be displayed in appropriate sources. I understand that processing all 500+ subprojects takes some time without any benefit for you, but I believe this is a cornercase - typically the projects aren't so big, typical NetBeans user doesn't have this sort of problems. I would like to do something for nbbuild, but I really don't see any reasonable solution except disabling profiling points for NetBeans modules at all, but that's probably not what we want.
jglick, could you please verify this issue?
I'm not sure what the fix was, but seems to be solved in a current dev build.