Could you please try a recent dev build (201205230300 or newer)? It should consume much less memory, leading to much faster analysis - although I cannot claim it will be significantly faster than FB, there is a lot to verify.

Thanks.

Jan,
I went to http://bits.netbeans.org/download/trunk/nightly/latest/ to grab the latest, but all the download links are inactive - except for the "All" - which I don't want (I always just get the "Java SE" bundle).

Assuming that this is some temporary bug on the netbeans site, I will try again in a day or so.

I will try out the daily later as well.  I am running NB 7.2 beta, on Window Vista (32 bit) with Java 7 update 4.

I ran the inspect, selecting only the Netbeans hints, and it came back after a few seconds (still seemed a bit long for just 7 class, however).

Then I tried it again, using just the Find Bugs analyzer.  It is just hanging (maybe 2 minutes now), no activity in the progress bar at all.  Not even the indeterminate sweep.

The site where I've always gotten the latest, http://bits.netbeans.org/download/trunk/nightly/latest/, still is only showing a download for the "All" package.  Is there something wrong at the site?  I'd like to try Jan's suggestion to see if things work better there than in the beta.

Trying with 201205300001.  Memory usage looks better, but it is still increasing.

It finally came back after about 15 minutes.  (9 small-ish classes, not 7 as I thought earlier.)  Maybe this is just how long FindBugs takes?

jconsole says:
  4 minutes from 300 MarkSweepCompact collections
  10.2 seconds on copy from 518 collections

I just started NB and ran the test right away.

BTW, the inspect actions still chooses the parent node to the one I select when I am viewing the packages as a tree or reduced tree.  When I view the packages as a list, the inspect dialog shows the correct node.

On the "Files" tab, selection is also incorrect.

However, for right click actions like "Find", the selection is always correct.

Petr, seems that downloading development builds for Mac is broken from:
http://bits.netbeans.org/download/trunk/nightly/latest/
For me, all the download links are disabled, for Thomas all except "All" are disabled. Could you please take a look on that? Thanks.

Thomas, as a workaround, I would suggest to use "OS independent zip" - should be enough to unpack it somewhere.

(In reply to comment #5)
> Trying with 201205300001.  Memory usage looks better, but it is still
> increasing.
> 
> It finally came back after about 15 minutes.  (9 small-ish classes, not 7 as I
> thought earlier.)  Maybe this is just how long FindBugs takes?

Sounds unlikely. How much memory do you have (either heap or physical memory - I can infer the default heap size from the physical memory)? It would be perfect if you could run the analysis under the "Profile me" feature:
http://wiki.netbeans.org/FitnessViaPartnership

and send the resulting snapshot.

Thanks.

Looks like the profile information doesn't have any heap data...meaning that our source code is not included?  It looks like it is just performance data of NB.  Is this true?

Also, where is the snapshot stored so I can send it to you?  (Providing there is no proprietary information in it.)

(In reply to comment #5)
> It finally came back after about 15 minutes.  (9 small-ish classes, not 7 as I
> thought earlier.)  Maybe this is just how long FindBugs takes?

I don't think so.  I remember running a standalone version of FindBugs on my project (4200 java source files) and that may have taken a few minutes, but 7 source files should be done pretty quickly).

(In reply to comment #8)
> Looks like the profile information doesn't have any heap data...meaning that
> our source code is not included?  It looks like it is just performance data of
> NB.  Is this true?

To the best of my knowledge, the file basically only contains data inferred from thread dumps. There might be some metadata on the info panel, but I only see things like the date when the snapshot was taken.

> 
> Also, where is the snapshot stored so I can send it to you?  (Providing there
> is no proprietary information in it.)

There is an "Export to..." button on a toolbar under the "Stack depth" section.

Thanks.

Created attachment 120078 [details]
profiler snapshot

I canceled after about 5 minutes of waiting.  It was up to about 88% I think.

From jconsole:

Committed: 
   380,160 kbytes
Max: 
   380,160 kbytes
GC time: 
     2 minutes on MarkSweepCompact (185 collections)

 8.319 seconds on Copy (310 collections)

(In reply to comment #1)
> Could you please try a recent dev build (201205230300 or newer)? It should
> consume much less memory, leading to much faster analysis

I tried the 20120604 build and when I do the inspect on the "NB Java Hints", on my 4252 java file project, it takes 12 minutes to be 50% done - I then had to do some work and had to cancel.  By comparison, when I later tried repeating the analysis using "Findbugs" - it took a total of 5 minutes to complete!

What is "expected" for an analysis on this number of files?  5 minutes for a FindBugs analysis seems in line with what I remember when I ran FindBugs standalone a year or two ago.  But the "NB Java Hints" seems ungodly slow.  I would certainly not use it at these speeds.  And it seems counter-intuitive that it should be slower than FindBugs - after all, being part of NB, it should have some "inside information" vs. FindBugs, no?

Again, I'm running this on a MacBook Pro running MacOS 10.7.4, JDK 1.6u31 and 8GB RAM (from the messages.log, it appears NB configured itself to only use -Xmx768m...is there a way to change that from the GUI? I know I can manually do so in netbeans.conf).

(In reply to comment #12)
> (In reply to comment #1)
> > Could you please try a recent dev build (201205230300 or newer)? It should
> > consume much less memory, leading to much faster analysis
> 
> I tried the 20120604 build and when I do the inspect on the "NB Java Hints", on
> my 4252 java file project, it takes 12 minutes to be 50% done - I then had to
> do some work and had to cancel.  By comparison, when I later tried repeating
> the analysis using "Findbugs" - it took a total of 5 minutes to complete!
> 
> What is "expected" for an analysis on this number of files?  5 minutes for a

I would expect the java.hints to take about the same time as FindBugs (might be somewhat faster or slower, but not on the order of magnitude). One of my testing projects is the javac, and the time consumed was almost exactly equal with the default setting and "unlimited"/default memory. With limited memory (-Xmx128m), the java.hints runs much slower, but finishes. FB goes out of memory. I will need to get a bigger testing project.

> FindBugs analysis seems in line with what I remember when I ran FindBugs
> standalone a year or two ago.  But the "NB Java Hints" seems ungodly slow.  I
> would certainly not use it at these speeds.  And it seems counter-intuitive
> that it should be slower than FindBugs - after all, being part of NB, it should
> have some "inside information" vs. FindBugs, no?
> 
> Again, I'm running this on a MacBook Pro running MacOS 10.7.4, JDK 1.6u31 and
> 8GB RAM (from the messages.log, it appears NB configured itself to only use
> -Xmx768m...is there a way to change that from the GUI? I know I can manually do
> so in netbeans.conf).

(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #1)
> > > Could you please try a recent dev build (201205230300 or newer)? It should
> > > consume much less memory, leading to much faster analysis
> > 
> > I tried the 20120604 build and when I do the inspect on the "NB Java Hints", on
> > my 4252 java file project, it takes 12 minutes to be 50% done - I then had to
> > do some work and had to cancel.  By comparison, when I later tried repeating
> > the analysis using "Findbugs" - it took a total of 5 minutes to complete!
> > 
> > What is "expected" for an analysis on this number of files?  5 minutes for a
> 
> I would expect the java.hints to take about the same time as FindBugs (might be
> somewhat faster or slower, but not on the order of magnitude). One of my
> testing projects is the javac, and the time consumed was almost exactly equal
> with the default setting and "unlimited"/default memory. With limited memory
> (-Xmx128m), the java.hints runs much slower, but finishes. FB goes out of
> memory. I will need to get a bigger testing project.

I tested (only lightly so far) on a project that consist of all NB platform sources in one source root (about 2000 Java files). The java.hints and FB appear to take approximately the same time with default settings (including memory). I took a profile me snapshot, and there are a few things that might improve the performance for java.hints, but I am not sure if that would help your case. Could you please try to take a profile me snapshot while running the Java hints analysis? Unfortunately, it will only keep 5 minutes of data, but I hope some patterns will be visible from that.

Thanks.

Ok, I can do that - but forgive the stupid question: HOW do I do that?  At first I looked for "Profile Me" and couldn't find any menu item named that.  Then I saw the toolbar button "Profile the IDE" and thought - oh, that would be easy.....but the problem is that I can't click on it while the "Inspect" window is up, since it appears to be modal.

BTW, I'm now running the 0608 build and stopped the inspection 6 minutes into it - with only 34% complete.

When I was doing that, I first started the profiling using the Profile the IDE button, and opened the dialog after that. To stop the profiling before the analysis finishes, I canceled the analysis and then stopped the profiling (it will open the snapshot in a profiler, where it can be saved).

Thanks.

Created attachment 120673 [details]
NB self-profile while doing NB Hints analysis

This is a Netbeans self-profiling snapshot of my project's "Source->Inspect->Netbeans Java Hints".  I started NB profiling, started then analysis, and then cancelled the analysis after about 6 minutes (33% done) and then stopped the profiling.

As mentioned before, the project consists of 4255 java files (7817 .class files).  The FindBugs analysis takes about 5 minutes in total.

Thanks for the snapshot. Unfortunately, there is no single obvious thing that would make the progress 5 times faster.

To highlight some points from the snapshot (total 298 seconds of analysis):
-about 170 seconds spent in parsing. Seems that a lot of that time is actually consumed by listing packages - not completely clear if that is the "native" time, NB filesystems time, or something simply being called too often. It may also be the case that the files were parsed by many instances of javac, which would make it much slower, but is not determinable from a snapshot, unfortunately. We will need to look at this more deeply.
-about 113 seconds spent by actually running the hints. Out of this, about 51 seconds are spent in the OrganizeImports hint, which I have already seen to be quite slow in other snapshots. I have an idea that might make it much faster (removing about 45 seconds, if everything goes well). There are a few more things that are reasonable candidates for optimization, taking in total 15-20 seconds (not sure how much can be actually saved from it). The latter are likely post-7.2, as they may have destabilizing effect. Anyway, effect any optimizations in this part other that the OrganizeImports one will be pretty limited considering parsing took a lot more time than running the hints.

For the record, I made a performance fix to the FB integration that should ensure that it consumes less memory and converts the FB results to internal NB structures faster:
http://hg.netbeans.org/jet-main/rev/d7f38ea90f7f
(I will bump the spec. version soon, so that a new version is visible in the AUC eventually.)

Making diffing inside OrganizeImports faster:
http://hg.netbeans.org/main-silver/rev/5fe7e15c1ef9

Bug #214181 describes another performance optimization.

Integrated into 'main-golden', will be available in build *201206150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/d7f38ea90f7f
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #213182: better performance creating ErrorDescriptions for FindBugs bugs.

Thomas, could you please try daily build 201206170001 - it should contain both the above fix and fix for bug #214181. Both of these improve the speed significantly for me. Judging from the profile snapshot from you, the speed-up is unlikely to be that significant for you, but double-checking that would be good. Thanks.

For the record, I tried running default configurations for both NB Java Hints and Findbugs over the java.hints module and all modules it depends on on my Linux. NB Java Hints took about 506 seconds, FindBugs 860 seconds (I run a lot more experiments recently, and these results are mostly consistent with them, considering the above two fixes). The results may of course differ based on a lot of aspects (OS, free memory/heap, project size/project count, etc.).

(In reply to comment #21)
> Thomas, could you please try daily build 201206170001 - it should contain both
> the above fix and fix for bug #214181. Both of these improve the speed
> significantly for me. Judging from the profile snapshot from you, the speed-up
> is unlikely to be that significant for you, but double-checking that would be
> good. Thanks.

Jan,
I don't see any improvement at all.  I started the IDE, built the project, and waited for all scanning/indexing to complete.  This time I let the NB Hints inspection run for much longer, but, as before, it seemed to get slower and slower over time (in terms of the progress bar): almost immediately after starting, it reached 10% and then became progressively slower.  By the time it reached 72% - after 47 MINUTES - the progress bar had come to a virtual standstill - I waited another minute, but it didn't move from 72%.  So I stopped it.

I then restarted the IDE re-built the project, waited until background scanning/indexing completed and ran Inspect->FindBugs.  It completed in 7 minutes.

It is possible that I'm not running the inspection with the same hints as you.  I vaguely remember adjusting them some time ago.  As there doesn't seem to be any "Revert to default" option on that screen (Preferences->Editor->Hints->Java), I'm not sure what to do next.  I see an "Export" that seems to allow one to export ones hint settings as a Zip file - would it help if I sent that to you?

Thanks for the testing, Thomas. I looked at the profiler snapshot again, and realized that the files are processed one by one instead of being handled in chunks. This is generally much slower. I am sorry I did not notice that before - the difference is quite small in the snapshot. That explains a lot from what you see. What project type do you use? Thanks.

(In reply to comment #23)
> Thanks for the testing, Thomas. I looked at the profiler snapshot again, and
> realized that the files are processed one by one instead of being handled in
> chunks. This is generally much slower. I am sorry I did not notice that before
> - the difference is quite small in the snapshot. That explains a lot from what
> you see. What project type do you use? Thanks.

No problem (with testing that is).  My project is a "Java Project with existing Source".  There are four source roots, with most of the source files in one of the roots.  The 4263 source files are spread over 592 directories/packages.

Let me know if you need me to do anything else.

Created attachment 121035 [details]
Binary patch that should make Source/Inspect much faster

Thomas, would you be willing to test this patch? Place this jar inside
${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-spi-java-hints
(${NETBEANS_INSTALL_DIR}/java/modules should exist, patches/org-netbeans-spi-java-hints needs to be created). The IDE should print something like this to the log:
INFO [org.netbeans.core.startup.NbEvents]: Module patch or custom extension: ${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-spi-java-hints/213182.jar

To revert the patch, simply delete the jar. I think the patch should be compatible both with a recent trunk and 7.2 RC1.

Thank you very much.

(In reply to comment #25)
> Created attachment 121035 [details]
> Binary patch that should make Source/Inspect much faster
> 
> Thomas, would you be willing to test this patch? Place this jar inside
> ${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-spi-java-hints
> (${NETBEANS_INSTALL_DIR}/java/modules should exist,
> patches/org-netbeans-spi-java-hints needs to be created). The IDE should print
> something like this to the log:
> INFO [org.netbeans.core.startup.NbEvents]: Module patch or custom extension:
> ${NETBEANS_INSTALL_DIR}/java/modules/patches/org-netbeans-spi-java-hints/213182.jar
> 
> To revert the patch, simply delete the jar. I think the patch should be
> compatible both with a recent trunk and 7.2 RC1.


Hi Jan - good news!  The patch worked like magic.  The analysis went from practically never finishing to finishing in about 6 minutes - on par with FindBugs.  Will this be included in a coming daily build?

Thanks for finding/fixing the problem.

Two quickj/final questions: (1) the "Hints" analysis cover only the "checked" hints under Preferences->Editor->Hints, right? (2) the online Help for the hints speaks of the following option:

     Show in problem window. Java only. Show the hint in the Output window as a problem.

This is actually what I've always wanted (I'm always the guy committing "violating" code to our source repository because, unlike Eclipse, a Netbeans users can't really see all their violations unless they happen to be looking into the gutter of each changed file).  Anyway, the actual screen doesn't have the option that the help speaks of :-(  Is this still coming in a future 7.2 build?

Great to hear that. I have committed to our trunk repository (will become part of NB version post 7.2), and will go through the process to include that patch in NetBeans 7.2:
http://hg.netbeans.org/jet-main/rev/4bab8a67705d

Thanks a lot for testing!

Regarding the note in the help, the note should not be there. At one point there was a plan to include the warnings in the Tasks window, but there is Source/Inspect instead of it now. I have filled bug #214452 for that.

(In reply to comment #28)
> Regarding the note in the help, the note should not be there. At one point
> there was a plan to include the warnings in the Tasks window, but there is
> Source/Inspect instead of it now. I have filled bug #214452 for that.

Jan, thanks for putting a patch in 7.2 for this.

I don't see how Source/Inspect is a good substitute.  If I've modified 30 files in a project of almost 5000 files, why would I want to run Source/Inspect on the whole project just to see whether I've committed any violations in the 30 modified files?  Even with the bug fix, I'd have to wait 5 minutes - and then my violations would be obscured by those others may have introduced into the project.

There should be another Source/Inspect option for only inspecting modified files or, better yet - from a workflow perspective - allow this to be integrated with the output window (I'm already looking at that every time I build - to have to manually do Source/Inspect is really clumsy.  That's why I looked forward to the feature described in the Help).

Should I file an enhancement bug for this or is there already one (perhaps resurrect the one that killed off the Preferences->Editor->Hints option?)

Thanks again.  Sorry for discussing this through this bug, but you seem to know about this area, so I'm abusing that knowledge :-)

(In reply to comment #29)
> (In reply to comment #28)
> > Regarding the note in the help, the note should not be there. At one point
> > there was a plan to include the warnings in the Tasks window, but there is
> > Source/Inspect instead of it now. I have filled bug #214452 for that.
> 
> Jan, thanks for putting a patch in 7.2 for this.
> 
> I don't see how Source/Inspect is a good substitute.  If I've modified 30 files
> in a project of almost 5000 files, why would I want to run Source/Inspect on
> the whole project just to see whether I've committed any violations in the 30
> modified files?  Even with the bug fix, I'd have to wait 5 minutes - and then
> my violations would be obscured by those others may have introduced into the
> project.

I realize there is such a usecase. The direction I would see viable would be to set-up a baseline (i.e. show a difference from an specific point - might be possibly integrated with VCS actions) and perform the refresh incrementally (likely only for java.hints - not trivial to implement, though, as change in one file can generally introduce or fix a warning in a different file).

> 
> There should be another Source/Inspect option for only inspecting modified
> files or, better yet - from a workflow perspective - allow this to be
> integrated with the output window (I'm already looking at that every time I

Sorry, but I'm not sure Output window is the correct place to show such warnings. Aside the fact that people using compile on save never see any compilation output, I see quite some other trouble. For example, what would happen when a clean build would be performed? Would it run the hints for 5 minutes and produce a lot of warnings to the output window? Moreover, would the hint be run on each build, slowing it down even if the change is actually adding a temporary debugging statement? How would be the difference from previous state be checked?

(For the record, I am playing with ability to run NB's hints on the command line, but I expect that to be useful mainly on continuous integration server.)

> build - to have to manually do Source/Inspect is really clumsy.  That's why I
> looked forward to the feature described in the Help).

I don't know why that was added to the help - I don't think it was ever considered to actually add the warnings to the output window. Adding it to the Tasks window was under consideration, although there never was more than one non-working prototype.

> 
> Should I file an enhancement bug for this or is there already one (perhaps
> resurrect the one that killed off the Preferences->Editor->Hints option?)

Sure, please do that.

> 
> Thanks again.  Sorry for discussing this through this bug, but you seem to know
> about this area, so I'm abusing that knowledge :-)

The patch seems OK to me.

(In reply to comment #31)
...
> > There should be another Source/Inspect option for only inspecting modified
> > files or, better yet - from a workflow perspective - allow this to be
> > integrated with the output window (I'm already looking at that every time I
> 
> Sorry, but I'm not sure Output window is the correct place to show such
> warnings. Aside the fact that people using compile on save never see any
> compilation output, I see quite some other trouble. For example, what would
> happen when a clean build would be performed? Would it run the hints for 5
> minutes and produce a lot of warnings to the output window? Moreover, would the
> hint be run on each build, slowing it down even if the change is actually
> adding a temporary debugging statement? How would be the difference from
> previous state be checked?

I used Compile-on-Save but turned it off when I found out that it didn't always handle file changes correctly (e.g. a public static String change in one file not percolating to already compiled class files using that variable) and there were no plans to fix that.  But I get your point - as I believe it it is now by default turned on.

Maybe I'm old-school, but my workflow still revolves around the "build->fix compile errors->run" cycle, so I'm constantly looking at the Output window, either to fix compile errors or to see debug statements from the running program.  That's the main reason I suggested it as a good place for hints to be displayed (with hyperlinks, like the compiler warnings/errors, so I can easily fix them in the source).

In that context, the analysis would simply be applied to the same set of source files that the compiler compiled.  EasyPMD2 (a NB plugin for PMD an analysis engine that does similar code analysis as the Java hints in NB) already does this - except its output goes into the Tasks/Action Items tab.  If EasyPMD2 has the information on what to analyze, I imagine NB itself would have it.  For full builds, there could be an option to not run the hints analysis.

(In reply to comment #32)
> (In reply to comment #31)
> ...
> > > There should be another Source/Inspect option for only inspecting modified
> > > files or, better yet - from a workflow perspective - allow this to be
> > > integrated with the output window (I'm already looking at that every time I
> > 
> > Sorry, but I'm not sure Output window is the correct place to show such
> > warnings. Aside the fact that people using compile on save never see any
> > compilation output, I see quite some other trouble. For example, what would
> > happen when a clean build would be performed? Would it run the hints for 5
> > minutes and produce a lot of warnings to the output window? Moreover, would the
> > hint be run on each build, slowing it down even if the change is actually
> > adding a temporary debugging statement? How would be the difference from
> > previous state be checked?
> 
> I used Compile-on-Save but turned it off when I found out that it didn't always
> handle file changes correctly (e.g. a public static String change in one file
> not percolating to already compiled class files using that variable) and there
> were no plans to fix that.  But I get your point - as I believe it it is now 

Actually, I would say the opposite is true - compile on save should handle changes to compile-time constants well (and if not, bugs like this are generally being fixed). It is the ant build that has problems with that, and that is unlikely to be solved.

by
> default turned on.

(In reply to comment #33)
> > I used Compile-on-Save but turned it off when I found out that it didn't always
> > handle file changes correctly (e.g. a public static String change in one file
> > not percolating to already compiled class files using that variable) and there
> > were no plans to fix that.  But I get your point - as I believe it it is now 
> 
> Actually, I would say the opposite is true - compile on save should handle
> changes to compile-time constants well (and if not, bugs like this are
> generally being fixed). It is the ant build that has problems with that, and
> that is unlikely to be solved.

Hm, yes, I'm co-mingling problems.  I had turned off compile-to-save because when that was on, I was always getting "non compilable code" runtime errors as I moved from one project to another.  I noticed that that was fixed just yesterday.  So maybe I'll go back to compile-to-save then.  Thanks for the correction.

So, if I lived in a compile-to-save world, I could still have a screens such as "Action Items" always open (instead of "Output") and expect NB to run the analysis on the changed files whenever they were saved, no?  I think that's what EasyPMD2 does (would have to check on that).  The question of the length of time a complete analysis would take would not occur.

release72:
http://hg.netbeans.org/releases/rev/3d2e76992561

Integrated into 'releases', will be available in build *201206212341* or newer. Wait for official and publicly available build.
Changeset: http://hg.netbeans.org/releases/rev/3d2e76992561
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #213182: should not rely on ClassPath.equals, as different instances of CP may be produced for different files under one source root.

Integrated into 'main-golden', will be available in build *201206220002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4bab8a67705d
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #213182: should not rely on ClassPath.equals, as different instances of CP may be produced for different files under one source root.

verified in 7.2

*** Bug 220095 has been marked as a duplicate of this bug. ***