View Full Version : Long running campaign slowing down performance
Gilafron
May 12th, 2024, 18:01
Hello, I have a long-running campaign and performance has taken a hit. I'm looking for tips to improve performance within Fantasy Grounds. Even standard approaches. Does it matter if I've shared a lot of maps or have a lot of modules or extensions activated? Do number of stories or loaded images impact it?
Zacchaeus
May 12th, 2024, 18:34
Short answer to all your questions is yes.
Unshare any images (especially any very large ones) that are no longer needed; reduce the number of modules you have shared (do the players need all the modules you have shared?). Do you really need this or that extension? If not disable them. Some extensions do use up a lot of resources because they do a lot of stuff. But useage is really down to personal preference; I'm not going to tell you to not use them. Slowdown could be because you or one of your players is running out of memory so cutting down on stuff you have shared may well help that.
Gilafron
May 12th, 2024, 18:38
Thanks Zaccheaus for the quick reply! I'll try these out.
LordEntrails
May 12th, 2024, 18:51
The other thing I do is I rename the chatlog.html every year or so. It can get pretty big and there is no need to keep it all in one file.
WinterSoldier7
May 13th, 2024, 19:24
Ah, this may explain a lot for me, too. I've been running the same campaign for four years and noticed I need to close any other open programs just to keep it reasonable :P
Is it ok to delete the chatlog.html?
anstett
May 13th, 2024, 19:54
If you delete the chatlog a new one will be created.
I prune my chat log every few months because we copy it to our wiki at the end of each session. I keep a couple of months in the chatlog so if any problems pop up I can go see what extensions were loaded at which times.
WinterSoldier7
May 13th, 2024, 23:22
Any idea what all these db.session xml's are?
Moon Wizard
May 13th, 2024, 23:27
They are backups of your db.xml that are created once per day (i.e. the first time you run FG each day, a backup db.session file is made.) This allows you to restore campaign data from backup in case of corruption to the main database. These are limited to the last 10 or the last 30 days; whichever is more.
Regards,
JPG
LordEntrails
May 13th, 2024, 23:45
Deleting it is fine. But if you rename it FG will create a new one and you will have the old one if you ever want to reference it.
WinterSoldier7
May 14th, 2024, 00:22
Thanks all.
Is there any way to see what the biggest memory hogs are?
I've gone through and unshared a load of things, deleted a load of assets that I wont be needing - not sure if they affect things.
Anything else I can do?
Laerun
May 14th, 2024, 00:28
Thanks all.
Is there any way to see what the biggest memory hogs are?
I've gone through and unshared a load of things, deleted a load of assets that I wont be needing - not sure if they affect things.
Anything else I can do?
Large maps, extensions, and hundreds of unnecessary tokens or map assets.
WinterSoldier7
May 14th, 2024, 00:30
Large maps, extensions, and hundreds of unnecessary tokens or map assets.
Oh no, so the assets all count even if you haven't saved them as image record or shared them?
If so, I'm damned.
LordEntrails
May 14th, 2024, 01:57
Oh no, so the assets all count even if you haven't saved them as image record or shared them?
If so, I'm damned.
I'm not sure. During the beta test, yes. It's why I don't have my tens of thousands of maps and assets in FG and keep them outside until I need them. But I think Moon has said that issue has been resolved, but I'm not certian.
But should be easy to test, launch FG and see how much memory it takes up when you open your campaign. Close FG and just move your whole tokens &/or images folder (or even rename it) and see how much memory it takes up.
Moon Wizard
May 14th, 2024, 02:46
Large images (>4Kx4K pixel resolution) will still cause issues, especially if they have FX, LoS, etc. Also, they will slow down the Assets window as well.
Regards,
JPG
WinterSoldier7
May 14th, 2024, 11:43
I'm not sure. During the beta test, yes. It's why I don't have my tens of thousands of maps and assets in FG and keep them outside until I need them. But I think Moon has said that issue has been resolved, but I'm not certian.
But should be easy to test, launch FG and see how much memory it takes up when you open your campaign. Close FG and just move your whole tokens &/or images folder (or even rename it) and see how much memory it takes up.
How do I check the memory it's using up? Is that the ol' CRTL+ALT+DEL?
Zacchaeus
May 14th, 2024, 12:24
How do I check the memory it's using up? Is that the ol' CRTL+ALT+DEL?
Yes, use the task manager. Either via CTRL+ALT+DEL or right click on the taskbar and select it from there or type Task into the search box on the task bar. There's probably some WINDOW+ other key that does it as well but those never work for me.
Trenloe
May 14th, 2024, 15:07
CTRL+SHIFT+Esc bring up the Windows task manager.
Zacchaeus
May 14th, 2024, 16:16
CTRL+SHIFT+Esc bring up the Windows task manager.
See, I knew someone would know another way :)
WinterSoldier7
May 14th, 2024, 23:17
Didn't see a whole lot of savings on removing the mass of tokens and images I have. Still, think it could do with a good culling.
Trenloe
May 15th, 2024, 01:01
@WinterSoldier7 - how big is your campaign db.xml file?
WinterSoldier7
May 15th, 2024, 20:29
@WinterSoldier7 - how big is your campaign db.xml file?
Looks to be 15,767kb.
I do have folders of tokens and images not in the campaign folder, though, if that matters.
Moon Wizard
May 15th, 2024, 21:48
That is a huge. My longest multi-year campaign sits at about 1800 Kb, though this is before LoS, so assuming under 3Mb for most campaigns.
Also, images/tokens in the FG data folder outside the campaign still count for the total.
Regards,
JPG
WinterSoldier7
May 15th, 2024, 21:54
Ok, crikey.
I'll do a bit of spring cleaning and see what happens
LordEntrails
May 15th, 2024, 22:10
Basically that is 16MB of text. Stories, items, NPCs, but no images. My ~5yr 5E campaign that ran from levels 1-20 ended up at 7MB. My undermountain campaign with ~600 stories, and similar numbers of NPCs, parcels and a bunch of items and spells is only 5.4MB.
It would be a lot of effort, but you can move a lot of history type of stuff into other campaigns/modules and then not have them loaded when you don't need them. To do this; Duplicate (and rename) your campaign into several "chapters" or regions. Go into each campaign and delete everything but the info for that "chapter". Then export that chapter to a module. In your original campaign, delete everything that now resides in one of your modules. Then load the module when you need it and unload it when you are not using that info.
If doing that, you can also see my guide on module creation linked in my sig to learn about Development Campaigns and best practices.
WinterSoldier7
May 15th, 2024, 22:21
Thanks, I think I will do that - good idea.
How easy is it to update and add to a module?
I think - and this will probably give you some insight into where all of that memory is going - I will break it down into countries. Players only going to be in one of those at a time!
LordEntrails
May 15th, 2024, 22:30
Keep the development campaign. Then anytime you want to update the module, update the campaign and re-export. As long as you have not modified the object (story, item, NPC, etc) in your play campaign, the new version from your Devl campaign will automatically be shown when you access it via your play campaign.
Trenloe
May 16th, 2024, 00:18
Ok, crikey.
I'll do a bit of spring cleaning and see what happens
One thing that can, depending on the ruleset, take up a lot of space is a PC record. If you've made copies of PCs in the campaign, or there's older unused PCs, you may want to export those to XML as backups and then delete the exported, no longer needed PCs, from the campaign.
MrDDT
May 17th, 2024, 07:00
This is a lot of stuff being thrown out and it's mixing up a little of what is "memory hog" and "lagging" and "slowing down".
Different things affect different performance issues.
The best thing to do is state what issue you are seeing, and we can go from there. Because there is a lot of cross advice going which might not even fix the issue.
Example of this is an image being 4kx4k or more, has no effect on loading your FGU, unless it's shared.
You might see a small issue with clicking on your assets window and seeing some delay, but having one located in FGU isn't going to cause loading lag or playing lag.
Having a large DB isn't going to make your assets load slower when you click on assets.
Some things also can't be fixed past hardware issues.
Basic advice like "renaming chat log" is good overall advice as most people don't even use the old chat log at all. (I delete mine all the time, sometimes after each session), the log is normally used to go back and find information if you needed it on what was said or done in chat.
I also would as basic advice make sure you zip up your whole campaign once in a while and back it up onto another drive if you have a long going campaign (or even off the computer onto a backup drive or cloud storage)
SylvanSnake
May 23rd, 2024, 18:11
Would be pretty cool if FGU could be optimized for 64-bit functionality. I imagine that's probably the biggest factor that causes slowdown. Need multi-threading and better memory utilization.
Moon Wizard
May 23rd, 2024, 18:27
I'm not sure what you mean; FGU is built as a 64-bit application. Multi-threading is used when possible; but can not always be used due to order of execution constraints for rulesets to work as expected.
The biggest slow-downs tend to be when people place very large amounts of images/graphics and text within their campaigns, or load up very large size images. For data, it's generally pretty good, as long as rulesets limit display of data to a fixed number of records. For images, using recommended sizes improves performance greatly. We are tweaking things regularly, but any system can be overloaded if you place lots of data into it.
Regards,
JPG
Laerun
May 23rd, 2024, 22:11
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/forums/showthread.php?38475-The-road-forward-64-bit-multithreading&p=339564&viewfull=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.atlassian.net/wiki/spaces/FGCP/pages/2037547009/Developer+Guide+-+Product+Guidelines
4.) Extensions can kill performance, depending on what they do.
A blog article regarding maps, etc. https://www.fantasygroundsacademy.com/post/maximize-virtual-tabletop-performance-a-gm-s-guide-to-map-los-optimization
Gilafron
May 23rd, 2024, 22:41
Is there a way to easily find all shared images?
LordEntrails
May 23rd, 2024, 23:30
Is there a way to easily find all shared images?
Yes, click the Shared filter icon on the bottom of the images list.
damned
May 24th, 2024, 00:48
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
May 24th, 2024, 06:07
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
May 24th, 2024, 06:22
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
May 24th, 2024, 14:16
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
May 24th, 2024, 14:17
@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
May 24th, 2024, 15:55
So it might not be the saving then :bandit:
I just created a 15M db.xml and it still saved in 0.6s on my average computer (with fast disk).
Trenloe
May 24th, 2024, 15:59
So it might not be the saving then :bandit:
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.
Powered by vBulletin® Version 4.2.1 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved.