Module Manager patch count

[cinemagic]

1) I've heard sayings that higher MM patch count will raise game's memory usage thus significantly slow you game, so you should keep it low as possible, is that true?

For me I think it's half true, any time I goes up to 80k patch count the game is definitely unplayable. But weirdly, my RP-1 build with 66k patch count can be loaded in 8 minutes, runs very smooth and stable, but another JNSQ+NFsuit+Pathfinder build with 48k patch count raises my load time to 12minutes, runs quite slow and crashes often.

I don't mean it's JNSQ+NFsuit+Pathfinder's fault, I always install through ckan and pick latest version, it's definitely some other mods or conflict that I don't know, thus it cames to question 2)

2) From my experience, some mods that doesn't add many parts or/ don't do much of background processing, are still adding tons of patches count to MM. (I just too lazy to recognize them one by one, sorry)

If your answer to 1)  is true, from your experience, which or what kind of mods is best to avoid since they add too much of patch count?

3) What is an acceptable MM patch count for a AMD R7-3700x / 16GBram rig?

4) I recently installed a new game focused on KSRSS+BDB+Tantares+Kerbalism, for kind of mini RO/RSS experience. After adding some essential (for me) QoL mods like alarm clock, antenna helper, etc, my MM patch count easily goes above 40k.

If this is too high, what's your suggestion on reducing it, or, what is your method on keeping your MM patch count as low as possible while still keeping a reasonable modding experience?

Edited June 24, 2022 by cinemagic

[Aelfhe1m]

Counting patches is a very poor way of judging game memory usage impact.  The only thing it really tells you is how much MM is modifying your game database during loading. Some patches are even deleting stuff.

A slightly better metric would be to look at the size of the GameData/ModuleManager.ConfigCache file after the game has loaded since this records the actual final information stored in the game database but even on a very heavily modded KSP instance this is unlikely to be more than about 100MB or so (and the space it takes up in game memory may be much less than that). A few large textures will have much more impact.

The main cause of increased memory usage in KSP is models and textures. Some mods that add a lot of parts might use shared textures to reduce their memory footprint (BDB for example) or even reuse the stock textures.

If you have memory concerns concentrate on pruning any parts you don't need/want and making sure to delete any deprecated parts (provided you're not using them in in-flight vessels). The perma-prune feature in The Janitors Closet by linuxgurugamer can be helpful for this but proceed with care, shared textures and models can cause issues if you delete a part that provided a texture/model that another part you didn't delete relies on.

Don't worry if adding a QOL mod suddenly makes your patch count jump up considerably. In general QOL mods have very little impact on memory usage compared to parts mods. One exception is Action Groups Extended which adds some large chunks of data to every part which can bloat the size of your save file considerably if you have a lot of vessels in flight - personally I find the trade-off acceptable for the added functionality.