You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Justification
When working with larger projects Rubberduck uses a lot of RAM (as we already know from #3347), depending on the programmer there is quite a lot Rubberduck does that isn't needed all that often. It would therefore be great if there was a way of running Rubberduck in "on-demand" mode where it only does a full parse when needed and frees up the memory it uses when it isn't needed any more. Personally I use the Code Explorer navigation all the time, and most of the other functionalities a lot less. When I use the other functions (such as reference finding, refactoring etc) it is normally when I am in a specific debugging mode and then use them a lot in a short time frame, but then a lot less after. Same with unit testing. For 90% of my time I am more than content with having the Code Explorer open and not much else. This could help alleviate the issues of high memory usage for a lot of people (assuming they use it as I do, which I don't know) until a better solution is in place. It might be that I am not making the full use of all of Rubberduck's features, but there doesn't seem to be that much that I use daily that requires constant knowledge of the code (like an intellisense autocomplete), most of it is on button click.
For my project running Rubberduck puts me at 1.5GB of memory use, in longer sessions it creeps up to 2GB and beyond. This makes the IDE freeze up at regular intervals (every 30-40 minutes or so), and adding new files etc (things that prompts an automatic reparse) takes a while.
Description
I'd really like it if it was possible to run Rubberduck in a minimal on-demand mode. Where it only does a cursory parse to populate the Code Explorer and doesn't keep more than what is necessary for that in memory. Then when one needs a fuller parse of the code (e.g. for a refactoring) it then does the full parse and possibly keeps the state for 15-30 minutes before disposing of it, requiring another reparse afterwards.
The text was updated successfully, but these errors were encountered:
Irubataru
added
the
enhancement
Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope.
label
Nov 18, 2020
Justification
When working with larger projects Rubberduck uses a lot of RAM (as we already know from #3347), depending on the programmer there is quite a lot Rubberduck does that isn't needed all that often. It would therefore be great if there was a way of running Rubberduck in "on-demand" mode where it only does a full parse when needed and frees up the memory it uses when it isn't needed any more. Personally I use the Code Explorer navigation all the time, and most of the other functionalities a lot less. When I use the other functions (such as reference finding, refactoring etc) it is normally when I am in a specific debugging mode and then use them a lot in a short time frame, but then a lot less after. Same with unit testing. For 90% of my time I am more than content with having the Code Explorer open and not much else. This could help alleviate the issues of high memory usage for a lot of people (assuming they use it as I do, which I don't know) until a better solution is in place. It might be that I am not making the full use of all of Rubberduck's features, but there doesn't seem to be that much that I use daily that requires constant knowledge of the code (like an intellisense autocomplete), most of it is on button click.
For my project running Rubberduck puts me at 1.5GB of memory use, in longer sessions it creeps up to 2GB and beyond. This makes the IDE freeze up at regular intervals (every 30-40 minutes or so), and adding new files etc (things that prompts an automatic reparse) takes a while.
Description
I'd really like it if it was possible to run Rubberduck in a minimal on-demand mode. Where it only does a cursory parse to populate the Code Explorer and doesn't keep more than what is necessary for that in memory. Then when one needs a fuller parse of the code (e.g. for a refactoring) it then does the full parse and possibly keeps the state for 15-30 minutes before disposing of it, requiring another reparse afterwards.
The text was updated successfully, but these errors were encountered: