Not possible to show TODO-List without creating code-database

[Gener4tor]

I use the TODO-List very much.

But I have the problem with getting it. It seems to be the only way for getting the TODO-List is clicking on Pending/Refresh.

Pending/Refresh creates not only the TODO-List but also the code-database.

So there is my problem:
As rubberduck uses excessive amounds of RAM when creating the code-database ms-access usually crashes soon after clicking "Pending/Refresh" because of "Out of memory".

As I can see it there are several solutions to my problem:

• A massive(=90%) reduction of rubberdukcs memory-consumption
• A way to only create/recreate the TODO-List

P.S.: My prefered solution whould be a switch to turn off the creation of the code-database completly. The features I use most (intender and TODO-List) dont use it anyway and there are a lot of actions which trigger the creation of the code-database automaticly and are resulting in a out-of-memory-crash of access.

[retailcoder]

If we don't parse the code, we don't know what todo markers are in it... also, the last couple of indenter bugs still present, will be much easier to address when the indenter uses the parse trees, as is the plan.

So basically, the proposal/request here is to put 99% of our work behind a kill switch to essentially cripple the add-in by disabling all the navigation tooling, code inspections, refactorings, ...everything.

I very much understand that memory consumption is an issue (c.f. #3347), but the solution is not going to be a "lame duck mode" that deactivates everything we've built in the past 5 years (be it only out of respect for this project's contributors and their incredible hard work). The solution is going to be to offload the database-y work out of the host process... and that's a lot of work that needs to be planned, with several options that need to be explored and experimented with. "A massive reduction of Rubberduck's memory consumption" is a project in its own right.

[bclothier]

Also -- in case you missed it, there is a open case ( #5176 ) to address the memory consumption. You also are more than welcome to help and contribute a PR to address the memory & performance issues.