Rubberduck: Very slow with 4318 findings

[SystemsModelling]

When I double-click a Code Inspection result, Excel goes "Not responding" and a few (3 or so) minutes later wakes up. Are 4318 findings a lot in a 30K line project?

This is not practically usable at present.
Of course I could disable many of the default observations but as a first run it's useful to run through them ... if I could only run. I might try exporting to Excel and writing a macro to jump from the finding to the place in the code, without RD running.

is there a General Setting to turn RD off temporarily, as distinct from unloading?

Rubberduck version information

Version 2.4.1.4729
OS: Microsoft Windows NT 10.0.17134.0, x64
Host Product: Microsoft Office x86
Host Version: 16.0.11629.20196
Host Executable: EXCEL.EXE

[Vogel612]

This seems to be duplicating #4928. As it stands, you want to disable automatic inspections after reparse. You can still get inspection results if you refresh from the Code Inspections toolwindow. For all other cases, Inspections will not be run.

[SystemsModelling]

Sure, but I have to run Inspections first to get the results, then unload RD and run my little SheetChange macro (on the sheet where I pasted the copied results ) that jumps to the offending line much more quickly than RD. My question is, is there a simple toggle rather than Unload? How about the performance? Would you expect a three minute wait after a double-click? If that's just how it is, I'll use this workaround.

[daFreeMan]

Posting a Debug level log might help identify what's causing RD to take 3 minutes to navigate from an inspection click to the location in code.

[ghost]

I notice a similar but much smaller delay for a Word project I have which currently has about 10k loc. I think this issue is mainly when you expose an existing project to rubberduck. It should be possible to switch off code inspections for each module with an annotation '@IgnoreModule' so that you can expose modules/classes 1 at a time and deal with a smaller number of issues. Unfortunately, this annotation doesn't seem to be working as expected at the moment. (See https://github.com/rubberduck-vba/Rubberduck/issues/4965)

[daFreeMan]

'@IgnoreModule works here just fine in Access on build .4734. I had .4729 installed yesterday, and wasn't in the VBE extensively, but don't recall having had issues with it of late (#4965 not withstanding).

I just tested it out to confirm - I get 18 inspection results in some "borrowed" code without it, and no mention of the module in my inspection results with it. (Tested in Access because I had a project open.)

[ghost]

That's useful to know. I've just tested again and indeed '@IgnoreModule is working in most cases.

[ghost]

@daFreeMan. Found the problem. Its the inspection result 'Public Member name contains an underscore' that is being ignored by '@IgnoreModule' annotation.

[daFreeMan]

@SteveLaycock that's an easy enough fix then, don't use underscores in Public Members!

This seems to be the a cause of #4965, so you may want to update it as well to note your findings.

[retailcoder]

@SystemsModelling the freeze with the inspections toolwindow is definitely not normal.

Barring review comments (and assuming a successful build...), that's everything I intended to go into this one. Note that I had to disable group virtualization to handle the expand and collapse all buttons, but when I did the second round of performance testing it turned out to be "acceptable" for the ~3000 inspection result project I tested on. Not instantaneous grouping changes, but sub 1 second. If this turns into a problem with enormous projects (10K+ results), we can revisit that decision.
_{https://github.com/rubberduck-vba/Rubberduck/pull/4717#issuecomment-459605806}

[SystemsModelling]

So, I started again, reloaded RD, opened the Code Inspections, waited a minute, clicked a finding and it was there in a second or two. Repeat, same result. Scrolling a page down takes a few seconds but not annoyingly so. I don't know what's different this time, so next time I start from scratch I'll be more methodical about recording the time so I know what part of the log corresponds to what I'm doing.