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.
While writing a patch for issue 169160, I noticed that the parsing API tries to look up the owning project for many files underneath the NetBeans install root. There is probably never a case where there will be a project present (see below - it actually is worse if your userdir is underneath $NB_SRC/nbbuild). This certainly slows down project scanning, and does pointless work; the project lookup should be skipped for such files. The behavior is even worse if you are running w/ $NBBUILD/testuserdir as your userdir, as the project for nbbuild/nbproject is looked up hundreds of times and this happens on every change in the system filesystem. See attached log - I added some logging code to log the stack trace whenever the call was to look up a project under $NB_SRC.
Created attachment 85208 [details] log file w/ stack traces
Several optimizations are possible here. The particular problem with the PHP module was that its VisibilityQuery was using FileOwnerQuery to look up a PHP project; my optimization simply first checks if any nbproject/ subdir of a parent exists. 1. Probably something like this should be done for all VisibilityQueries, or ideally centralized if possible. FileOwnerQuery should be a last resort, not the first choice. 2. Detect if running under $NB_SRC/nbbuild/testuserdir and correct for that situation - while this is not useful to users, it means that when we are doing development and testing changes, the IDE is behaving the same way it would behave for a normal user (i.e. not trying to find a project for every file in the system filesystem every time a file in the system fs changes). Right now, running with a userdir under nbbuild means that every system filesystem change triggers a call to VisibilityQuery and resolves $NBPROJECT/nbbuild as the owning project. That both makes performance measurements when running w/ testuserdir meaningless (the IDE is doing extra and different work), and means that when we are trying to reproduce bugs, we are not really running in a similar environment to the bug reporter. Currently 3. Where possible, if a uniquely named file is present under $PROJECT/nbproject or some other file signature test (e.g. "phpproject" instead of "nbproject") can be applied to determine if a project is really owned by a particular project type, many VisibilityQuery implementations could probably avoid the expense of reading the project.xml, or at least delay it until the project instance is really needed.
Created attachment 85211 [details] Log file over testuserdir - 95 calls to isVisible() including for such files as nbbuild/testuserdir/var/cache/index/s7/java/14/checksums.properties
Adjusting the category.
All events under the indexing chache folder are now quickly filtered out. http://hg.netbeans.org/jet-main/rev/ee9f0595df2e
Integrated into 'main-golden', will be available in build *200908080201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-golden/rev/ee9f0595df2e User: Vita Stejskal <vstejskal@netbeans.org> Log: #169166: filtering out events concerning files under the indexing cache folder