Limit which projects get and how much gets parsed.

[robodude666]

To my understanding Rubberduck currently parses every project/reference in an attempt to know EVERYTHING possible about the code. This is great -- if you're dealing with a small code base. However, in cases where there are multiple VBA Projects loaded or very complex references being used this can cause Rubberduck/VBE to be unresponsive.

It would be great if Rubberduck could support per-project/reference configuration for how deep to parse. For example, if there are four projects loaded:

• 3rdPartyCode1
• 3rdPartyCode2
• MyColleaguesCode
• MyCode

the two 3rdPartyCode VBAProjects contain thousands of identifiers, procedures, etc. that you may have no control over. It's also code you can't edit. It would be handy for Rubberduck to know about what modules and procedures exist, but it shouldn't care about identifiers inside of those procedures, private members, etc. The Code Inspection tool should ignore these.

However, MyColleaguesCode and MyCode is code I care about and would want it parsed 100%. The Code Inspection tool should display issues with these projects.

For some more detail, I support VBA code that depends on 3rd party XLAs that contain over 7 MB of code. Having Rubberduck parse these projects consumes over 1.5 GB of ram, takes 5-15 minutes to parse, and the code inspection tool either stops working or takes over 60 minutes to display anything.

[robodude666]

An alternative solution would be to only parse the active project 100% and only parse other projects to a limited scale (so that the Rubberduck Bar keeps working). Then have the Code Inspection tool only display issues with the current active project.

Secondly, an global option should be supported to blacklist projects by name/path so they're never parsed.

[ThunderFrame]

Linking (possible duplicate) #1520

[retailcoder]

Ouch.

I think we can do this.

• ParseActiveProject setting would process the active project (and its dependencies)
• ParseVBE would process everything in the VBE (and their dependencies)

As for the 3rd party XLA's, are the projects not locked? Rubberduck doesn't parse locked projects. If they don't need to be maintained then you can lock them as a work-around, until we resolve this.

[ThunderFrame]

How about a light parse? Only resolve the public members of a project?, so that a client-project can still fully resolve?

[retailcoder]

@ThunderFrame that can be done, by introducing another parse pass.

[retailcoder]

One side-effect of skipping a project is that the Code Explorer couldn't display it. Unless, yeah, a public members pass picks up the highlights.

[robodude666]

Regarding the 3rd party XLAs, no, they're not protected.

If the user elects to run in a limited mode, I see no issue with the Code Explorer not showing stuff for projects they don't care about.

Regarding "and their dependencies" -- would it be possible for Rubberduck to only parse top-level module names and prototypes without it parsing all of the procedure implementations? Likewise, for COM references is there any way of reducing the amount that gets parsed? i.e. lazy or "JIT" parsing?

[Vogel612]

@robodude666 while what you propose sounds nice, it's basically impossible. Sure we can ignore information in the parser "results" (like local variables), but we either need a separate grammar for such public parsing (which doesn't necessarily mean the parsing will be faster), or we just parser everything into a parse-tree and then do a parse-pass that simply ignores everything that's not module-scope (which probably would give us a bit of a speed up and some memory benefits)....

As soon as we can shotgun-surgically parse on the module level properly, this huge overhead is something that will only be the initial parse, which from my PoV seems good enough for now.

[MDoerner]

Since we do not reparse or reresolved modules neither modified nor referencing a modified module, the performance hit for the parse occurs only in the initial parse. However, the inspections are always problematic, cf. issue #3043.

I would like to suggest a new feature, whose basic building blocks are already there, as an alternative to the light parse: we could add a possibility to serialize the declarations for selected projects and then load the projects the user selected similar to how we load COM references. We could also treat these declarations as built-in, which would exclude them from basically all inspections.

[robodude666]

Would it instead be possible to have Code Inspection only return results for the current active project?

[retailcoder]

@robodude666 not now, no. But the Inspection Results toolwindow is on its way out anyway.

[bclothier]

I am adding this to the Type Information API project because we have a new option: Instead of parsing the referenced projects, we can just read off the type information exposed by that referenced project. That will allow us to resolve all references but without having to parse the reference project.

Whether this will yield a performance gain, however, is questionable, because while we might have spared ourselves the task of parsing, we still have to run the collection for the resolution. At least inspections need not run for such projects resolved in this manner.

[SystemsModelling]

Just checking - it's still the case that to suppress parsing addins or indeed any other workbook open at the same time as the workbook under test I need to protect their VBProject with a password?

[bclothier]

This is my understanding, yes.

Briefly reviewing the PR #4535 suggests to me that in the end no changes was made due to some blocking issues which existed at that time of merging the PR. This should be no longer a blocking issue since that the PR #4706 was also merged which also fixes issues with loading user projects. When a PR is started on that subject, it will likely impact the question of how locked projects will get parsed.