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.
Summary: | ProfilingPointsManager.processOpenedProjectsChanged slows down project opening | ||
---|---|---|---|
Product: | profiler | Reporter: | Jesse Glick <jglick> |
Component: | Base | Assignee: | Jiri Sedlacek <jis> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | issues |
Priority: | P2 | Keywords: | PERFORMANCE |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Representative excerpt from a thread dump |
Description
Jesse Glick
2007-07-10 00:35:47 UTC
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. |