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 154663 - Task scanning is slow
Summary: Task scanning is slow
Alias: None
Product: java
Classification: Unclassified
Component: Source (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker with 8 votes (vote)
Assignee: Jan Jancura
Depends on:
Reported: 2008-12-05 00:17 UTC by frankioski
Modified: 2009-06-02 10:37 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attaching screen cap of task scanning (211.16 KB, image/png)
2008-12-05 00:18 UTC, frankioski

Note You need to log in before you can comment on or make changes to this bug.
Description frankioski 2008-12-05 00:17:11 UTC
Task scanning takes like 15 minutes to finish. Why?  I start NB at 3:58 pm. Task scanning ends at 4:12 pm.
Comment 1 frankioski 2008-12-05 00:18:11 UTC
Created attachment 74560 [details]
Attaching screen cap of task scanning
Comment 2 Peter Pis 2008-12-05 06:35:30 UTC
Reassigning to java for evaluation.
Comment 3 Pavel Flaska 2009-01-07 11:18:42 UTC
Perhaps because of slow network disc access I guess. Not sure, you didn't add some useful additional information.
Try to describe your environment in maximum detail. (OS, number of projects and their size), usage of NFS, messages.log etc.

Comment 4 meinholz 2009-01-07 12:49:53 UTC
This happens to me also on Windows XP, jdk 1.6.0_11. I had to uninstall the Task List plugin to make netbeans 6.5 usable
for me. I only had 3-4 smallish projects without a lot of dependencies and it took several minutes to complete task
scanning. All projects were on the local hard drive, no network file systems were involved in the projects.

This was a very vanilla install of netbeans on a windows computer. This problem made usage of netbeans out of the box
unusable without deinstallation of the plugin. IMO, this will really hurt the adoption chances of netbeans.
Comment 5 Jan Jancura 2009-02-20 11:55:38 UTC
Thanks for your report. I am trying to reproduce it, but I am not very successful. I have several questions:
1) how many tasks you see in your Tasklist?
2) have you changed Task List settings? For example, have you changed Task List Filter?
3) Do you use one JDK for all your projects?

Comment 6 rburkhead 2009-03-14 17:36:56 UTC
Having the same problem on a very large php/html project (several hundred files). Tasklist settings have not changed
from the default installation. No idea how many tasks the tasklist manager might find, as it is the first time I
attempted to open that project.  After a few seconds, the UI became unresponsive, and the nbexec job had to be killed at
the OS level.
Comment 7 neu242 2009-04-29 08:50:07 UTC
There's a test case for this in (Apr 28)
Comment 8 greggwon 2009-05-26 20:29:44 UTC
I've done some more testing of where things get ugly, by taking some dependencies which I had identified as libraries,
to instead be on projects so that the output of the project build would be used as the dependency, instead of the
library jar file which would be copied into place as part of the library project build.

It looks to me like this is a workaround.  I still feel like the problem is that freeform projects have basically no
tracking built into them.  It seems to me that there could be an easy path from a library jar to a project by allowing a
library to have a path designation that is the "project" that builds that library.  I know that this is basically
covered by switching from a library to a project dependency as exists today.

However, my issue is that I always want to build against the production library build, no matter who built that library
for several of my libraries, so I really don't know how to address the async update issue of that library without being
able to say this library comes from this project.  You can already say this library comes from these sources, and it is
already the case that only one project can include a source tree, so that might be the dependency that needs more
inspection at the moment that the library is detected as updated, and then NB could find exactly what had changed.