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.
Now adding new items for project is done in the UI thread. This isn't critical if user adds one or several files. But if "add existing items from directory" is invoked for large projects (like MySQL, which has more than 2000 files), UI hangs for minutes. This is unacceptable.
I think, it's P2, because significantly affect responsiveness and performance. And at the same time no any notification to user about long-time taks. Impl. comment: don't use Vector for big collections. Synchronized ArrayList is 2 times faster than Vector.
See also http://cnd.netbeans.org/issues/show_bug.cgi?id=76817
seems, we can improve speed up by changing listener. now we have: for each new added file { inform all listeners that new file was added } => for listeners it´s impossible to estimate how many other calls it will have. we can do: create list of all new files for each listener { inform listener about added list of files } In this case we (code model part) could provide progress to indicate that some number of files is under parse. Although one problem still remains. ¨create list of all new files¨ is expensive => project system should enforce progress bar in infinite state as well for indicating some activity. And of course this phase should be moved out from UI thread.
Yes, creating a queue of files being added and putting it into parser queue in a separate thread will improve sutuation a bit. But even when code model switched off at all, UI hangs for more than a minute when user adds 2000 files to a project.
Now files are added to the project from a seperate thread. This fixes the major problem in this issue. There are other good suggestions in this bug report of how to improve performance. I will close this issue as dup of 76817 now the main issue has been fixed and deal with all performance issues at once. I don't believe these are so bad that they are p1 or p2. *** This issue has been marked as a duplicate of 76817 ***