Moon you are missing the point

[Moon Wizard]

@BushViper,

Thank you for making a new thread to specifically report your issue. I responded in that thread about additional information and testing that could be helpful.
https://www.fantasygrounds.com/forum...l=1#post628956

JPG

[Moon Wizard]

And just to be clear, I closed the other thread specifically to keep people from just jumping into a potentially unrelated thread with random performance comments without providing any information. While some people believe that these reports are all correlated; the timing and symptoms have quite a bit of variety on when they're occurring based on the anecdotal reports, and it's more likely that they are separate issues. Without specific details for each person's situation and data, it's not a very useful discussion.

So, please post any reports in their own threads with as much data on the details as possible about what was going on, whether issues are occurring.

Here's a list of possible questions:
* What does "performance issues" mean in your scenario? (i.e. what exactly is running slow? dice rolls? window opening? mouse cursor? token movement? ...)
* Can you open Windows Task Manager when this is occurring? What are the detailed numbers for the Fantasy Grounds process? What are the numbers when restarting FGU from scratch with the same campaign?
* Have you tried playing without extensions and get the same problems? If so, can you narrow down which extension is causing the issue?
* When the slowdown is occurring, what is the state of the tabletop? (which exact windows are open? what was the flow of play in opening/closing windows? ...)
* Can you recreate the slowdown consistently, or does it just happen after a period of time? (If time related, the table state and usage flow is very important.)

Also, here are some things I would want people to try when a slowdown occurs to help us narrow down the scenario:
* Have one player shutdown FGU completely and restart/connect from scratch. Do they see the same slowdown after rejoining, or only the people that didn't reset?
* Have the GM close all IMAGE windows. Does the GM see the same slowdown after re-opening only the current map? Do the players still see the same slowdown after this test?
* Have the players close all IMAGE windows. Do they see the same slow down after re-opening the single map window in progress?
* Have the GM close all windows. Does the GM see the same slowdown after re-opening only the current map and combat tracker? Do the players still see the same slowdown after this test?
* Have the players close all windows. Do they see the same slow down after re-opening the single map window in progress?
* Does having the GM shut down and restart the session fix the slowdown when the players reconnect?

Regards,
JPG

[LordEntrails]

For those of you on Windows, their is a utility included called Performance Monitor. It is like a the Task Manager, but on steroids. The important part of it is that you can have it automatically create log files. This allows you to record the memory usage over time (and other data sets if you want). This means that the performance logs can be compared to the FGU logs. And that you don't have to write down or record what the memory is at the begin or end of the session.

[Weissrolf]

Smitework is still trying to fix your cars while the reason for traffic jams and crashing is the road being bumpy, partly broken, heavily bottlenecked and full of detours. They are either unwilling or incapable of fixing the road and as the thread title suggests maybe even incapable of even recognizing the potholes while being busy painting the houses on the sides of the road.

If Moon took the effort to read and understand the data presented and ask questions instead of sulkily closing threads left and right then he might have noticed that Smiteworks' main job is to do road construction for their paying customers, instead of telling people to have their cars fixed and extras removed. It's the classical (Steve Jobs TM) "You are holding it wrong" argument, where the company shifts the blame on the customer even for fundamentally broken design.

What we seem to know so far:

- Autosave causes FGU to fall into a broken state, but seemingly only if FGU is busy while an autosave happens. This would need real debugging (console work) to be done by SW for proper analysis. I presented reproducible test cases to do that work, but these were dismissed as unrealistic edge cases.

In practice there may be dozens of autosaves without problems and then there is the one where FGU was too busy to do it properly. This is one possible explanation for the sporadic/hard to reproduce nature of problems experienced by users in practical gaming sessions.

- Once Autosave pushes FGU over the edge memory consumption keeps increasing at a much faster pace compared to normal operation, as memory deallocation seems to be broken then. We don't know yet if other parts of FGU are also affected after the breaking point, but the pure fact that memory keeps being allocated points to FGU maybe having to deal with more and more data than necessary internally. So this is not so much about memory running out, but about data being shoved around.

- From a pure memory usage point of view the ongoing allocation of virtual memory (pagefile) is even more problematic than physical memory usage. By default Windows 10 and 11 allocate a maximum of 4 times the physical memory as virtual memory. So a 4 GB system (minimum FGU specs) only allows a maximum of 16 GB virtual memory for all applications and OS. Once that maximum is hit everything goes down the drain, likely with FGU crashing to the desktop (after some time) and Windows and other applications not working properly anymore unless you wait a long time or just restart.

- Overall FGU uses far too much memory for data objects, be it images or text. It allocates manifold the memory needed for each data object, it's a real memory pig! And again, this may not so much be a problem of free memory being available, but of bloated data having to be processed and even breaking FGU's internal workings. Various of my test cases that caused high memory load usually did not release memory by returning from the game to the lobby, I had to restart the FGU client instead (including the next point).

Data processing related observations:

- If any connected client or the GM paste very large chunks of text into their chat input then their respective FGU client behaves very choppy concerning anything chat window related (including rolls).

Once the pasting client hits Enter to send the text to chat all connected player and GM clients are affected by the same choppiness until they restart their respective client. It is not enough for the "offending" player (original paste) to restart their client.

- Displaying/drawing a list of text data, like PF2 Feats "By Level" sorted list, causes so unbelievably high CPU load that my frame per second drop from several thousands (Vsync off) to below 15. FGU has a surprising hard time processing and displaying text and image data considering that this is its very main objective to begin with.

So even without anything being broken FGU already show various bumps and bottlenecks fulfilling its tasks, but once your car stumbles over a pothole the screws come lose and everything falls more and more apart until you restart the car and maybe even return to an earlier part of the road.

Professionally Smitework has lost my respect quite some time ago and they have not seen any new money from me since February. For the time being I will rather spend my money being a patron to "PDF to Foundry" than buying further modules for FGU. FG will likely still serve me in its original purpose (for me) of handling encounters at f2f table games. But I will start a new online campaign using the other VTT and with gained experience will also try to switch my ongoing campaign over in time. The latter mainly depends on how my players' PCs handle the switch and my wish to get away from the SW community, not so much on features being gained or lost.

[jharp]

My christmas wish is a FGU test build that is instrumented for memory leaks.

Jason

[Zacchaeus]

- Displaying/drawing a list of text data, like PF2 Feats "By Level" sorted list, causes so unbelievably high CPU load that my frame per second drop from several thousands (Vsync off) to below 15. FGU has a surprising hard time processing and displaying text and image data considering that this is its very main objective to begin with.

Is this something that used to happen or still does? I just tested this (since it's a simple thing to test) and before I opened the list by level my memory usage was 1276Mb and after it opened was 1293Mb so a 20Mb or so increase. The operation happened immediately with no slowdown or anything. I've no idea what my framerate was before or after but i didn't see anything which would indicate that it dropped. Do you think this might be dependent on something like Graphics cards or other computer specs? Mine isn't cutting edge or anything so I'd expect to see some kind of similar result to yours or somewhat worse if you have a higher end machine.

[BushViper]

Is this something that used to happen or still does? I just tested this (since it's a simple thing to test) and before I opened the list by level my memory usage was 1276Mb and after it opened was 1293Mb so a 20Mb or so increase. The operation happened immediately with no slowdown or anything. I've no idea what my framerate was before or after but i didn't see anything which would indicate that it dropped. Do you think this might be dependent on something like Graphics cards or other computer specs? Mine isn't cutting edge or anything so I'd expect to see some kind of similar result to yours or somewhat worse if you have a higher end machine.

I might be stepping out of my line answering for him, but by the looks of his post (for this particular situation) accessing that file causes a massive spike in CPU (not memory) load that dumpsters his PCs framerate.

I can also reliably reproduce (real-world) situations where my PCs framerate dips to single digits and stays there until I close and restart FG. Obviously, trying to play a game with frames in the 5-20 range is not feasible.

[SilentRuin]

Holy.... I now understand why the thread was closed if this is the "reasoned" approach and commentary it took.

I personally don't have performance issues I've not been able to resolve with extensions and selective map/LOS/Lighting use. I mean that's all relatively new and still undergoing changes as we speak. In fact, Dec. 7 or there abouts is a big update coming.

To me its pretty simple - Problems happen - priorities assigned - developer assigned to one at a time - limited developers.

Customers enraged - spamming of duplicate issues with no real duplicatable process abound...

Yeah. I get it now.

Here is what will happen. FGU team will try to address problems as they come up - likely the ones they can duplicate (nice campaign provided with step by step process showing duplicatable issue) being addressed first as long as it does not require some horrific rewrite or some technical time consuming thing that would put a number of other priorities off the table. So they will proceed as they can.

Good users will provide duplicatable stuff that does not get buried in some spam thread.

Others will scream - threaten to leave - and generally say "MY ISSUE IS THE IMPORTANT ONE". I definitely relate to that. As I to feel I'm the center of the universe.

Still, I get why they can't have threads just go on and on and on about the same thing with no additional substance.

This thread - by example - has cleared up what was going on for me. Thanks.

[Weissrolf]

Is this something that used to happen or still does?

It always happened, still does and is known to Smiteworks and Trenloe. One of FGU's workarounds (detours) is to break such simple text lists into multiple pages to somewhat get around the CPU bottleneck. It is a classic example of data being processed in the least effective way possible. Ok for the first few releases to get things going, but not ok to not be revisited for months and years when it keeps failing on such a fundamental level.

It has nothing to do with memory size (despite FGU using too much RAM for simple text), nothing to do with the GPU (it's idle due to not being served data) and everything to do with how lists are handled by FGU's CPU thread. It's a pure expression of failed software design which the developers refuse or fail to improve. This PC is a modern car, but the road is more of an acre.

Twenty (20!) lines of text bring one of the most modern PCs down to its knees while other software does not even trip over millions of lines of text.

[BushViper]

It always happened, still does and is known to Smiteworks and Trenloe. One of FGU's workarounds (detours) is to break such simple text lists into multiple pages to somewhat get around the CPU bottleneck. It is a classic example of data being processed in the least effective way possible. Ok for the first few releases to get things going, but not ok to not be revisited for months and years when it keeps failing on such a fundamental level.

It has nothing to do with memory size (despite FGU using too much RAM for simple text), nothing to do with the GPU (it's idle due to not being served data) and everything to do with how lists are handled by FGU's CPU thread. It's a pure expression of failed software design which the developers refuse or fail to improve. This PC is a modern car, but the road is more of an acre.

Twenty (20!) lines of text bring one of the most modern PCs down to its knees while other software does not even trip over millions of lines of text.

That GIF is so illustrative of one of the many problems, it brings a tear to the eye.