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 43164 - Population of fields in Open Project dialog is not responsive
Summary: Population of fields in Open Project dialog is not responsive
Status: CLOSED FIXED
Alias: None
Product: projects
Classification: Unclassified
Component: Generic Infrastructure (show other bugs)
Version: 4.x
Hardware: All All
: P2 blocker (vote)
Assignee: Petr Hrebejk
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 41535
  Show dependency tree
 
Reported: 2004-05-12 15:59 UTC by Antonin Nebuzelsky
Modified: 2006-03-24 09:52 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
1ms sampling (89.96 KB, image/png)
2004-05-24 17:16 UTC, Antonin Nebuzelsky 		Details
1ms sampling (the other attachment is in fact dynamic instrumentataion!) (58.53 KB, image/png)
2004-05-24 17:17 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-05-12 15:59:19 UTC 
When you choose a folder in the Folders panel of
Open Project dialog, Project Name and list of
Required Projects have to be populated. Currently
it is done in AWT thread, freezing the UI for many
seconds if this project has many required projects
(e.g. refactoring project).
Comment 1 Petr Hrebejk 2004-05-19 16:17:07 UTC 
The population of the required projects should be pretty fast so there
should be no need for doing it in different thread. 
As you are the performance team please add some more data about what
was the IDE doing during the AWT was frozen. (Btw. I can't reproduce
it) This might be a more serious bug, which has to be fixed differently.
Comment 2 Petr Hrebejk 2004-05-19 16:17:49 UTC 
Probebly better to reassign to people than groups.
Comment 3 Jesse Glick 2004-05-19 18:09:12 UTC 
I can't reproduce a delay of more than a second even for NB module
projects with a lot of deps.

Anyway if it is true only for NB module projects and not for e.g.
j2seprojects then we don't care much.
Comment 4 Antonin Nebuzelsky 2004-05-24 17:15:39 UTC 
Ran CPU profiling. Going to attach two pictures with invocation trees,
one from dynamic instrumentation measurement method, another one from
1ms sampling measurement method.

It shows that ProjectChooserAccessory.getProject(),
ProjectChooserAccessory.addSubprojects() and
ProjectChooserAccessory.fillSubProjectsModel() are the methods where
the most time is spent. Which does not surprise anyone I guess. :o)
Anyway not sure if these methods (and/or the methods these call) can
be made faster.

So, if nothing else, at least hour-glass cursor should be used...
Comment 5 Antonin Nebuzelsky 2004-05-24 17:16:24 UTC 
Created attachment 15098 [details]
1ms sampling
Comment 6 Antonin Nebuzelsky 2004-05-24 17:17:34 UTC 
Created attachment 15099 [details]
1ms sampling (the other attachment is in fact dynamic instrumentataion!)
Comment 7 Jesse Glick 2004-05-24 22:25:26 UTC 
According to the instrumented log at least, most of the time is spent
in apisupport/project-specific methods, which do some things that are
more complex than j2seproject, e.g. loading a display name from
bundle, loading modules.xml, etc. So I'm not convinced this is a
serious problem unless the delay is also noticeable with
j2seproject's, for which no data was provided. Of course, if it is
straightforward to do the subproject population asynch anyway, we may
as well, to better handle slow-loading project types.
Comment 8 Petr Hrebejk 2004-07-23 10:02:00 UTC 
Should be better now.
Comment 9 Antonin Nebuzelsky 2004-07-26 10:15:24 UTC 
Works as expected now. Thanks.