Performance Issues with decent system

[Booker Grimm]

Two of my players are having slow down issues with lighting enabled. The map I'm using does have a number of lights, but should this be slowing things down to a crawl?
Connection speed is fine and no issues and when I disable lighting they report no problem.

Just curious if anyone else is having major slowdown with lighting enabled.

Thanks.

[Zacchaeus]

https://www.fantasygrounds.com/forums/showthread.php?67514-Poor-Performance-After-Yesterday-s-Update

https://www.fantasygrounds.com/forums/showthread.php?67564-Latest-test-game-in-TEST-server-that-was-painful

[zBeeble]

Urm... fix the foundation before you fix the trim. I have a s***t-kicking system. I have a 16 core threadripper, 64G overclocked RAM and a 2T NVME SSD. I have a lot of modules an extensions loaded (lots of rob2e, for example) but what I don't understand are the following slowdowns.

1. Minutes to load the campaign. It takes longer than Cyberpunk 2077 to get into my current campaign.

2. Scrolling slowdowns for large character sheets. Really... by 100 or so spells, it becomes "clunky"

3. palpable "seconds" to load a map.

All of these things are strange to me because I know what my system can do. There pretty much isn't faster disk available. Maybe a 10% single core advantage on the processor to some Intel things... maybe 25% better single core to the best AMD right now... but we aren't even loading 3D geometry...

[The Decepticon]

Urm... fix the foundation before you fix the trim. I have a s***t-kicking system. I have a 16 core threadripper, 64G overclocked RAM and a 2T NVME SSD. I have a lot of modules an extensions loaded (lots of rob2e, for example) but what I don't understand are the following slowdowns.

1. Minutes to load the campaign. It takes longer than Cyberpunk 2077 to get into my current campaign.

2. Scrolling slowdowns for large character sheets. Really... by 100 or so spells, it becomes "clunky"

3. palpable "seconds" to load a map.

All of these things are strange to me because I know what my system can do. There pretty much isn't faster disk available. Maybe a 10% single core advantage on the processor to some Intel things... maybe 25% better single core to the best AMD right now... but we aren't even loading 3D geometry...

It takes you minutes to get into a campaign? I never timed from when I clicked the button to getting into a campaign, but I would have to say it is no more than 30 to 45 seconds, if that. Most of the maps I have pulled up are pretty much instanteous and I never have to pause my game or wait for a map to load.

I will admit I have not had the issue with the spells as I have not had over 100 spells loaded on one character sheet. That's a pretty powerful wizard!

My system is no where even close to yours, so not sure why you are seeing those long load times.

[zBeeble]

It takes you minutes to get into a campaign? I never timed from when I clicked the button to getting into a campaign, but I would have to say it is no more than 30 to 45 seconds, if that. Most of the maps I have pulled up are pretty much instanteous and I never have to pause my game or wait for a map to load.

I will admit I have not had the issue with the spells as I have not had over 100 spells loaded on one character sheet. That's a pretty powerful wizard!

My system is no where even close to yours, so not sure why you are seeing those long load times.

Well... obviously, time-to-load is related to amount of data --- maybe you don't have all of rob2e. Whatever. 30 to 45 seconds is still too long. Cyberpunk 2077 loads in 10 or 15 seconds for the first time. loading a map is related to the map size and/or also all the rest of the stuff. My _complaint_ is that the constant multiplier on this amount of data is too large (if you want to be technical).

As for a 100 spells? Not hard for a 15-ish level wizard to have well over 100 spells. Not memorized --- and there inlies a clue --- when I have "combat" mode on --- only my 20 or 25 memorized spells + a dozen or so class/race abilities (which are coded as spells) is significantly faster (even to move the window around) than when preparation mode is active and all spells are visible.

Heck for a scroll wizard, their 14th level ability involves forgetting some number of spells to nullify incoming damage --- so they're literally _encouraged_ to have a large number of spells known.

[Moon Wizard]

Time to load is directly related to the number of products installed, as well as the number of assets (images/tokens) installed.

How many modules do you have in your module directory?
(Same for images and tokens...)

JPG

[zBeeble]

I have 144 modules. Maybe around 40 loaded ... 6 or 8 for the base game and things like tasha's, 2 for the module I'm running and about 30 for rob2e to automate things that really should be in the base game.

But that's not the thing... the average mod is (say) 5 megabytes compressed ... mostly of XML in the case of rob2e. These are taking 5 to 10 seconds to load each according to the debug output and there seems to be more delay that's not accounted for by that number. That's not a reasonable XML parsing rate --- this game is slow in so many ways that don't make sense. Optimization is required.

But the slow in loading is tolerable being before the game. Load all the 1-15 level cleric spells into a cleric and then go into preparation and scroll the character sheet up or down --- or even just try to move the window in preparation mode. That's painful.

[Moon Wizard]

With 40+ modules loaded, I'm going to suggest that you're going to see some performance issues. The compressed size of the data is not relevant; as the data has to be exploded into memory and objects created to represent each data node and record. I would suggest unloading any modules that you are not immediately using for a game. Just a suggestion.

We are aware that large lists have a performance issue; but have not been able to identify yet nor time to investigate heavily. This is worse on FGU, but still an issue on FGC. For clerics, we only recommend adding the memorized spells to the character sheet for the best performance.

Regards,
JPG

[zBeeble]

I get the temptation to "doctor when I do this it hurts" -> "Then don't do that" ... but ...

Is this project not boost-enabled? Are you not rich enough to afford good C++ coders?

... Sorry ... that was out-of-line. You should at least acknowledge that this _is_ a problem and it _is_ on a list somewhere. Acknowledging where it is on the list would be cool too :).

The fact that a list of 100-ish spells can drag down the window-moving interface says to me that you need to move from an object system that touches everything in the stack when an item in the stack is touched to only touching the items that need be rendered _after_ the whole stack has settled. Simple, but often missed GUI simplification.

But further on, given that you should be able to walk many 100's of megabytes of data per second (possibly even several gigabytes) ... how does a list of 100 items slow you down anyways --- that just begs the astonishment.

And there lies the reason for my post. I realize some of what you done, but even given some of my most pessimal assumptions... there's got to be some glaring bits that are being overlooked. Buy yourself a profiler, maybe? I recall them costing the earth back-in-the-day (in the 1000's per seat), but it's sorely needed here.

Asking users to pare down their spell lists ... well... have you met my cleric? :-/...

[Moon Wizard]

One consideration that I think many people miss is that because the FG client is a platform with an API; there are a lot of things that we cannot assume about how each piece of code needs to interact with others, nor what APIs will be called. Every piece needs to implement every interface, which is much more memory and performance intensive.

As I mentioned in other places, we only have two engineers that work on the main client code (of which I am one; but I split my time working on ruleset code and answering questions too).

Given that, it would be nice to be able to point at an exact spot in the code, and say I'll fix that and it fixes everything. However, the FG engine is very complex and there is no simple way to determine exactly what piece of code is the problem. Believe me, we've worked with the Unity performance tools, and they are very limited as to the amount of data they can handle (which FG exceeds).

If this was a large pre-packaged game title, we would break things into levels, minimize textures loaded, and many more optimizations. However, as a general purpose platform, you can't assume any of that.

Regards,
JPG

[zBeeble]

I'm actually recommending you run it through a profiler --- not unity's but say ... urm is Purify still the gold standard? Looks like DTrace on Linux could give you a tonne of insight w/o paying for something like Purify.

Back in the 90's, I worked on a team of C++ coders doing a Satellite image processing system. It was in the several millions of lines of code category and we had even decided (due to targeting 12 platforms as diverse as DOS, WinNT, VMS/OpenVMS, UN*X and MacOS and different hardware for many of them) to roll our own window system. Our team was about 10 coders, IIRC.

We were finally convinced to buy Purify ... and it was expensive ... as I said $1k per seat or so... and multiply that times a couple of the platforms we supported (purify didn't support all of them and we figured that we'd bag the big wins in code that was shared). As you might expect, there were enormous wins in 1% of our code --- and we did make good use of that Purify licence.

Do your own due diligence. I've heard Purify spoken of over time --- but there's a lot more open source stuff like DTrace around than there was then...

[Jiminimonka]

I get the temptation to "doctor when I do this it hurts" -> "Then don't do that" ... but ...

Is this project not boost-enabled? Are you not rich enough to afford good C++ coders?

... Sorry ... that was out-of-line. You should at least acknowledge that this _is_ a problem and it _is_ on a list somewhere. Acknowledging where it is on the list would be cool too :).

The fact that a list of 100-ish spells can drag down the window-moving interface says to me that you need to move from an object system that touches everything in the stack when an item in the stack is touched to only touching the items that need be rendered _after_ the whole stack has settled. Simple, but often missed GUI simplification.

But further on, given that you should be able to walk many 100's of megabytes of data per second (possibly even several gigabytes) ... how does a list of 100 items slow you down anyways --- that just begs the astonishment.

And there lies the reason for my post. I realize some of what you done, but even given some of my most pessimal assumptions... there's got to be some glaring bits that are being overlooked. Buy yourself a profiler, maybe? I recall them costing the earth back-in-the-day (in the 1000's per seat), but it's sorely needed here.

Asking users to pare down their spell lists ... well... have you met my cleric? :-/...

I have seen enough posts on the forums from Moon Wizard and other devs to see they do acknowledge the problems. I also see self declared experts comparing totally different systems to FG.

This paragraph got deleted because I don't want a forum ban....

[zBeeble]

I have seen enough posts on the forums from Moon Wizard and other devs to see they do acknowledge the problems. I also see self declared experts comparing totally different systems to FG.

This paragraph got deleted because I don't want a forum ban....

I'm sorry you had something too controversial to say. I have long lost many of the filters I had in my youth, but don't take anything I say as being a "self declared expert" ... or whatever that slur is. I don't believe anything I've said above is controversial. I know by many different means what my workstation can process. I have a good scale of the throughput of a processor, a PCIe bus and peripherals. I don't know anything of FGU code, but I know what's possible. I know this because I test it (for various reasons) and because it interests me.

When I compare this knowledge or (say) Cyberpunk 2077 (for which I also don't have code) I'm comparing things of equal or higher complexity to FGU. It's not that I've counted code points in either, it's that 2077 is clearly a more complex application and problem. But I could have equally compared (say) Skyrim with a large pile of mods (or Skyrim SE ... which is appropriately 64 bit). I can actually compare XML formatted configuration vs XML formatted configuration in that case. Skyrim actually packs it's config in a binary manner --- but if packing the data somehow would solve our problem ... then it's a solution that we should adopt (tho... I don't really believe it is --- I'm just offering a contrarian example).

I asked about acknowledging the performance issues because I was getting a lot of push-back --- as if what I saw was reasonable. I talked about profilers because they said that the unity supplied tools were ineffective. I know effective tools exist for this job because I've used them. Why haven't I used them more recently? Largely because the speed of machines has increased so rapidly that I don't require them for my code and my situations. I also, frankly, have DTrace (in FreeBSD, for me) on my side --- so I haven't had need of things like Purity --- although I did also suggest DTrace (which I use often) might be an effective solution.

Anyways... I'm rambling. I stand by my thought that good profilers are probably part of the solution. The amount of data we throw at FG isn't the problem. Heck, FG is probably one of the smallest steam downloads I've seen in a long time.

I have a substantial investment in Fantasy Grounds. I have substantial interest in it improving. Thus, I appear and make some noise about what's annoying me lately.

Sigh... I feel I won't convince the unconvinceable. I've given an easily applicable test: a cleric with 15 levels of cleric spells in "preparation" mode. Let's start with that problem. It's easy to reproduce and I've heard it from many players ... so it's not uncommon.

[damned]

I've given an easily applicable test: a cleric with 15 levels of cleric spells in "preparation" mode. Let's start with that problem. It's easy to reproduce and I've heard it from many players ... so it's not uncommon.

Its also easily avoidable in the interim, until a fix is found, kill the cleric and let her roll up a new Level 1 toon!

[Trenloe]

I've given an easily applicable test: a cleric with 15 levels of cleric spells in "preparation" mode. Let's start with that problem. It's easy to reproduce and I've heard it from many players ... so it's not uncommon.
See post #8. The devs are aware of the issue but haven’t been able to identify the root cause, nor had the bandwidth to do a deep investigation. The recommendation of only adding the memorized spells wasn’t a fix, but a suggested work around.

[LordEntrails]

I will also add, is a 15th level cleric with all spells really that common? If you parse the data published from D&D Beyond over the last year, the number of active characters greater than 10th level was something like 10 percent (random guess from a faulty memory). So while yes, spell lists are a problem, and performance in general is a problem, perhaps a more common used benchmark would be a better place for discussion.

[Zarestia]

OP hasn't replied once after starting the thread. Originally this was about lighting (TEST channel) which still has problems and is getting worked on. Somehow this got hijacked into a discussion about action tabs and what not. Devs have to priorise some things before others.

A few workarounds for the action tab problem were already said:
- don't pick every spell, only those you need (you wouldn't write down hundreds of spells onto paper when not playing online, right ...)
- play in combat mode for the most time and only prepare once per ingame day
- once the actions tab is clicked the first time, don't close the charsheet. after the initial caching it is way smoother (at least from my experience)

I only got a lvl 11 druid player who doesn't complain too much about it.

If OP still got some errors or issues with lighting, you should post in Laboratory (if the issues aren't already open there).

[LordEntrails]

OP hasn't replied once after starting the thread. Originally this was about lighting (TEST channel) which still has problems and is getting worked on. Somehow this got hijacked into a discussion about action tabs and what not. Devs have to priorise some things before others.
MOD: Point made. Thread closed. BookerGrimm can contact me or a moderator if they would like the thread re-opened.