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 222804 - Modifying independent C++ files causes a large reparse
Summary: Modifying independent C++ files causes a large reparse
Status: NEW
Alias: None
Product: cnd
Classification: Unclassified
Component: Code Model (show other bugs)
Version: 7.3
Hardware: PC Linux
: P3 normal (vote)
Assignee: issues@cnd
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-11-27 10:08 UTC by christiaensm
Modified: 2012-11-28 12:33 UTC (History)
0 users

See Also:
Issue Type: ENHANCEMENT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description christiaensm 2012-11-27 10:08:08 UTC
I have a big project (a complete parse reports > 2000 files analyzed) to which I've added two new files: a C++ header and a C++ class file. Within the remainder of the source code, there is no reference (yet) to these two files.  While I'm editing these two files, Netbeans regularly decides to reparse a large fraction (> 1000) of the files in the project.   I have no idea why since these files cannot influence anything inside the project (yet).  During such a reparse, performance is seriously degraded.  Auto-completion takes tens of seconds.
Comment 1 christiaensm 2012-11-27 10:57:23 UTC
Just wanted to add that the situation seems to be intermittent.  When you just start working, everything runs smoothly.  Then, Netbeans (for some reason I don't know), decides to reparse a lot.  This takes more than a minute.  If you continue to edit during this period, it seems that Netbeans continues to try to catch up and never really gets back to normal, fluent operation.  If you wait a couple of minutes so that everything reaches a quiescent state, then editing runs smoothly again and Netbeans doesn't reparse huge quantities of files.
Comment 2 Vladimir Voskresensky 2012-11-27 11:05:25 UTC
1) what is your NB version info (Help->About)
2) Can you confirm, please, that files are really independent from others by looking at mentioned source file using editor's popup menu Navigate->Include Hierarchy. Does your source file really not include any other headers files from project?
3) try to run NB with -J-DDeepReparsingUtils.level=-1 and attach $userdir/var/log/message.log here, please
Comment 3 christiaensm 2012-11-27 12:54:32 UTC
(In reply to comment #2)
> 1) what is your NB version info (Help->About)
> 2) Can you confirm, please, that files are really independent from others by
> looking at mentioned source file using editor's popup menu Navigate->Include
> Hierarchy. Does your source file really not include any other headers files
> from project?
> 3) try to run NB with -J-DDeepReparsingUtils.level=-1 and attach
> $userdir/var/log/message.log here, please

1) Build: 201211240959 (today)
2) I think you misunderstood: my 2 additional files are not #included by any other files in the project.  The 2 additional files do #include files from the project. 
3) I've added the option to my command line.  As soon as I see the issue re-occurring, I'll provide a log.
Comment 4 Vladimir Voskresensky 2012-11-27 14:40:45 UTC
(In reply to comment #3)
> 2) I think you misunderstood: my 2 additional files are not #included by any
> other files in the project.  The 2 additional files do #include files from the
> project. 
Ok. So your files are not independent, they depend themselves on other files of project. Header files are always parsed in the context of compilation units, that's why if you change your source file i.e. by adding/removing #include directives => it will cause parse of included files (don't forget about the fact that #includes are multi level in depth).

With all the above it's an enhancement.
It would be a bug if you observe the following:
- changes in source file below the last #include directive cause massive reparse.
Comment 5 christiaensm 2012-11-28 12:33:31 UTC
I've been running with DeepReparsingUtils enabled.  Most of the time, things are ok but now I have some strange behavior.  

I've added a header file (boost/regex.hpp) to a C++ file (object_mkcol.cpp) and edited the C++ file a bit more.  That triggered a parse of > 1000 files.  The parse was running on 1 or at most 2 cores so quite slow (I have allowed 30 parser threads since I have 16 cores, so that's a bit strange).  I don't know why that full parse was started.  

I think the following log section describes what happened: 

...
INFO [DeepReparsingUtils]: tryPartialReparseOnChangedFile /home/ampli/tmp/DSS-CPP/src/cpp/dsscontrollerd_pp/http_rest/object_mkcol.cpp
INFO [DeepReparsingUtils]: partial reparseOnChangedFile was enough for /home/ampli/tmp/DSS-CPP/src/cpp/dsscontrollerd_pp/http_rest/object_mkcol.cpp
INFO [DeepReparsingUtils]: tryPartialReparseOnChangedFile /home/ampli/tmp/DSS-CPP/src/cpp/dsscontrollerd_pp/http_rest/object_mkcol.cpp
partial reparseOnChangedFile results in changed signature for /home/ampli/tmp/DSS-CPP/src/cpp/dsscontrollerd_pp/http_rest/object_mkcol.cpp:
HASH - 876879902
HASH + -1998461117
  1   I:boost/algorithm/string/predicate.hpp
  2   I:boost/system/system_error.hpp
    + I:boost/regex.hpp
  3   I:object_mkcol.hpp
  4   I:util.hpp
  5   I:responder.hpp
INFO [DeepReparsingUtils]: full reparseOnChangedFile /home/ampli/tmp/DSS-CPP/src/cpp/dsscontrollerd_pp/http_rest/object_mkcol.cpp
INFO [DeepReparsingUtils]: tryPartialReparseOnChangedFile /home/ampli/tmp/DSS-CPP/target/debug/api/dssclient_exn.c
...

The object_mkcol.cpp file is an ordinary C++ file.  It's not #included in others so I would not expect other files to be impacted by this change.  I _would_ expect that if I changed the corresponding header file that other files are impacted but not by the .cpp file itself. 

BTW. It would be useful to have time stamps in the log file.  It makes it much more clear what events probably belong together.