It’s never “not actively doing anything”. Even if the menu itself is closed, there’s a lot that goes on in the background to make sure all (enabled) features function as intended.
As I’ve explained in an earlier comment (see link below), there’d need to be a lot of changes for this resource, and it’s dependency MenuAPI, to see any significant performance improvements.
I started creating this resource at the end of 2017, released it for the first time in March 2018. A lot of new features have been added in the 1.5 years that followed. I wasn’t the same person back then as I am now, knowing what I know now, I would’ve designed many things differently to be more efficient.
That’s an obviously easy thing to say right now, because I haven’t figured out how to time travel yet and fix my mistakes from 2+ years ago.
Why won’t I just fix it now?
Well it’s not as easy as it sounds. There’s a LOT that’d need to be changed, and for the amount of work that’d be, I might as well start from scratch. Which would take another 6 months to get a somewhat decent version working again. And I don’t have that much time to dedicate on a full rewrite either.
By the time I’d have completed a full rewrite, a LOT would’ve been changed, new natives would be available and new ‘best practices’ would also be in place, which I couldn’t have implemented before.
That’s a normal development cycle, you make something, and by the time you’re done, new improved ways of doing things become available and your oldest parts of the code is now just old and inefficient.
Many of the tools we have nowadays weren’t a thing 2 years ago, like the resource monitor, and other tools to profile a resource’s performance. And even a lot of natives were undiscovered back then, so a lot of my code, is using inefficient old natives, because there were no alternatives back then.
Previous comment about performance: