A more technical explanation, not only as a reply to you, but also as a general clarification for everyone.
Why does VAM run slower, feel less stable, and crash more often in a “messy” install compared to a clean install?
If you have ever noticed that your everyday VAM install, the one with hundreds or thousands of VAR packages accumulated over time, runs a scene at around 70-80 FPS, while the exact same scene reaches 100+ FPS in a clean install, this is not placebo.
A 30-40% framerate difference caused by unused VARs is real and explainable.
The core reason is this:
VAM 1.x is not fully lazy-loaded.
In other words, VAM does not completely ignore content just because the current scene is not using it. A lot of content gets indexed, registered, or prepared globally during startup or scene loading. So the more VARs you have installed, the more entries VAM may need to scan, track, iterate through, and garbage collect.
Main culprits, ranked by impact
1. The morph database, usually the biggest factor
Every Person atom builds a morph slot array indexed against the full AddonPackages morph collection. After the scene loads, per-frame morph evaluation still walks through that array while checking for active morphs.
This means a 5,000-morph library and a 50,000-morph library can have very different CPU costs per frame, even if the scene itself only uses 30 morphs.
Unused morphs are not completely free. Empty slots still take space and can still add iteration cost.
This is also why the preloadMorphs: false flag in meta.json can matter a lot.
2. Global asset registries
Clothing items, hairstyles, materials, textures, decals, and CUA assetbundles can all register into global pools when VAM scans your packages.
Bigger global pools can mean slower lookups, longer GC scans, and higher memory bandwidth usage. VAM also keeps VAR metadata such as meta.json, contentList, and thumbnails resident in memory.
3. Memory pressure, cache misses, and GC pauses
VAM runs on Unity 2018 and uses Mono’s garbage collector. More installed content can mean more live object references for VAM to keep track of.
A bloated AddonPackages folder increases the working set. This can lead to more CPU cache misses, higher memory pressure, and more frequent or longer GC stalls.
So when you see 70-80 FPS instead of 100+ FPS, the average framerate may be getting pulled down by small periodic stutters and garbage collection hitches.
4. Background scanning
Hub integration can periodically scan VAR metadata. The file browser also builds package indexes, even when you are not actively using it.
These background systems are useful, but they are not completely free.
Practical takeaways for players
• A clean VAM install is usually closer to the real performance of the scene itself.
• A long-used VAM install with many unused VARs can be permanently slower.
• If you want to test how well a scene really performs, do not benchmark it in your messy main install.
• The standard community recommendation is to keep two VAM installs:
Main / library install
Use this one to keep everything you have downloaded.
Clean playable install
Use this one for large, complex, or performance-sensitive scenes. Only install the scene and the dependencies it actually needs.
For big integrated scenes, this can make a very noticeable difference. A clean install may improve FPS, reduce stutters, lower random loading issues, and give you a much more accurate idea of how the scene is supposed to run.
