Long running campaign slowing down performance

[Laerun]

This has more to do with the engine, Unity does not natively support multi-threading. This does not mean that the core of Unity is not multi-threaded, but projects built on the Unity platform are not necessarily able to be multi-threaded.
Source: https://www.fantasygrounds.com/forum...l=1#post339564

Occasionally, a large campaign may require some general house keeping and optimization on the part of the GM.
1.) Clean up campaign folders if possible. (Several images and huge maps and hundreds of tokens unneeded tend to stack up and take a toll after awhile, I learned this the hard way...)
2.) Unload any unnecessary books and assets like maps, or un-share unneeded images. (Most games only need a couple core rules and perhaps a module or two, character creation is one of the few exceptions to the general best practices, and can be unloaded after building PCS or leveling up.)
3.) Image sizes, format, and use case suggestions are available here. https://fantasygroundsunity.atlassia...uct+Guidelines
4.) Extensions can kill performance, depending on what they do.

A blog article regarding maps, etc. https://www.fantasygroundsacademy.co...s-optimization

[Gilafron]

Is there a way to easily find all shared images?

[LordEntrails]

Is there a way to easily find all shared images?

Yes, click the Shared filter icon on the bottom of the images list.

[damned]

The campaign db is loaded into memory and periodically (every 5 minutes plus you can also manually initiate it) written to disk. It takes 5x longer to write a 15MB file than it does a 3mb file. That is going to have an impact every 5mins. Faster drives will also reduce that impact.

[SylvanSnake]

Well, I don't know much about the inner workings of FGU or the Unity engine, but when the db writes to disk is that just GM side, or is it for all clients? I can see how it might affect performance. Is there any way to set it up to only write the data that changed in the last 5 minutes instead of overwriting the entire campaign directory?

Disk writing shouldn't be an issue for me because my FGU data folder is on 3 fast SSDs linked in a RAID 0 configuration. But it's probably one of those cases where the slowest PC affects everybody and some players are actually playing on low-powered laptops.

[damned]

The db.xml exists only on the GM computer but the 15mb file will still take 5x longer than a 3mb file which is the next largest size reported in this thread. If it causes a 2sec delay at 3MB it will be a 10sec delay at 15MB.
The db.xml is a single flat file vs a database that has keys and values that are each written to separately so the answer is no it cannot write only the changes when it writes to disk - in memory it writes only changes. Adding an actual db engine will increase the complexity and the resource requirements - I am not saying it couldnt/shouldnt be done but it does add other factors to consider.

As for your local disk setup - I hope you have regular backups. RAID0 means a failure on any drive will result in loss of data on all three drives.

[Trenloe]

You can check how long the auto save takes. Look in the FG console (type /console in chat) and you'll see something like [5/24/2024 7:14:39 AM] Campaign saved. (0s) In this example, with a very small test campaign, the save took 0 seconds.

[Trenloe]

@Gilafron - what ruleset are you using (sorry if you've already mentioned that, but I didn't see it mentioned) and, as suggested previously, how many PCs are there setup in the campaign - go to the Characters screen to see all of the campaign PCs.

[damned]

So it might not be the saving then
I just created a 15M db.xml and it still saved in 0.6s on my average computer (with fast disk).

[Trenloe]

So it might not be the saving then
I just created a 15M db.xml and it still saved in 0.6s on my average computer (with fast disk).

It's always possible that it could be an issue - good to check.

I remember a couple of years ago a long thread about slow saving and I know cpinder did a lot of dev and testing to improve the auto save side.