That's not too far from the 'usual' to expect out of VAM if you have a lot of .VARs and/or don't manage your Cache.
The main culprit though (and is well known) is too many .VARs. However, there's not much you can actually do about it if you simply have the reflex (or habit) to just accumulate .VARs and don't get rid of the ones you'd know you don't need (past maybe 1 or 2 tries, you'd know if you'd want to keep this or that Scene, or Asset, or Clothing item or whatever is included in the .VAR, if it's outside of an actual Dependency you can just get rid of things help alleviate the problem that way).
The 'ideal' scenario to deal with this problem with VAM 1.x is unfortunately not very efficient and not realistic to expect out of most Users. Ideally, we'd all have to keep our installation of VAM in a relative 'fresh' state with a minimal amount of extra added content to it. So in a scenario where you'd have say... 500+, or 1000+, or 5000+ .VARs you'd then have to filter through the whole thing yourself, separate them by "themes" maybe, and then create separate VAM installations, each one having a specific theme of installed content, but with a much smaller total installation size, which would dramatically boost Startup times AND would also help with actual in-VAM performance as well.
Because, yes, if you have too many .VARs installed, and if your VAM takes multiple minutes to open up then that - in and of itself - is already a sign that your installation is 'bloated' (by VAM's standard and capabilities mind you). My personal "limit" is about 1500 to 2000 .VARs, within that range. Beyond that I'm waiting 3+ minutes for VAM to open up and my performances are taking hits in most scenes (by comparison to a fresh, or very light-weight installation).
But... obviously, not everyone would endure the headache of filtering through their .VARs (specially past the point of already having hundreds or thousands of them) and figuring out what they should separate from the rest in order to create another VAM installation. As I said, it's not "efficient" nor is it realistic to expect VAM Users to do it, but it IS what should be done to truly 'fight' this problem of degrading performance (and program Startup times).
So outside of doing the 'Multiple VAM Installations' thing... you only have few options to help alleviate the problem a little bit:
1) Clean your Cache.
2) Delete unnecessary .VARs (stuff you know you don't use or go back to, or if it's not an actual Dependency Asset, just get rid of it).
3) Make sure you don't have Duplicated .VARs (happens much more easily then you might think). Check your Error Log when you start up VAM in the main menu, and see which files are listed as Duplicates and remove those right away, you don't want to have Duplicates, it takes up space for no reason and bloats up the installation for no good reasons either.
And... that's about what you can do. Sure, the whole SSD thing can help a bit but believe me, you WILL wait minutes even on the fastest M2 drive if all you keep doing is accumulating content and not 'cleaning' up your installation once in a while. I'm also on a good Samsung SATA SSD and my original 'big bloated' installation was 360 GB+, with 5500+ .VARs and took me about 4:50 to maybe 5:10 minutes to open up; and that's on an AMD 7900X3D with 6000Mhz 32GB high quality RAM on an SSD. Doesn't really matter if you got a PC that's not even out yet from the future. VAM is notorious for this problem, all we can do is manage through it.