PDA

View Full Version : High CPU use and memory hog using grouped skills



Trenloe
December 19th, 2011, 00:46
Has anyone noticed this before? I've done a search and couldn't bring anything up...

I have a character with quite a few skills (don't we all?) and I've used the group functionality in the skills tab of the character sheet. When I select "Group" the CPU usage of Fantasy Grounds goes up and memory use starts to rise. If I leave the character sheet open on the skills tab my Fantasy Grounds takes up more and more memory and eventually crashes out just short of 2GB memory use (Fantasy Grounds just stops running - no warnings, it just disappears). Also, while taking more CPU this way there is a distinct lag in displaying dice rolls etc from the player in question.

If I switch to another tab in the character sheet or disable grouping, memory use drops down to the original level as does CPU use.

Any ideas on what could be causing this? I'm presuming something constantly looping to do the grouping?

damned
December 19th, 2011, 09:00
is this similar to what happens when you open 8 or 10 windows inside FG?

Trenloe
December 19th, 2011, 09:05
is this similar to what happens when you open 8 or 10 windows inside FG?
Don't think so mate - as simply disabling grouping from the radial menu stops it happening.

lachancery
December 21st, 2011, 03:35
I confirm a sharp increase in CPU when a character is opened on the Skills page and it is set to "Grouped". When I ungroup the skills, the CPU goes back down.

I am not seeing any memory leak when monitoring resources though. The memory usage increased when grouping, but it remained stable at the increased amount.

For the test, I have put about 45 skills in 5 different groups. I was not doing anything else within FG during the test. On the attached images, FG is using the third CPU.


Has anyone noticed this before?

I have a character with quite a few skills (don't we all?) and I've used the group functionality in the skills tab of the character sheet. When I select "Group" the CPU usage of Fantasy Grounds goes up and memory use starts to rise. If I leave the character sheet open on the skills tab my Fantasy Grounds takes up more and more memory and eventually crashes out just short of 2GB memory use (Fantasy Grounds just stops running - no warnings, it just disappears). Also, while taking more CPU this way there is a distinct lag in displaying dice rolls etc from the player in question.

If I switch to another tab in the character sheet or disable grouping, memory use drops down to the original level as does CPU use.

Any ideas on what could be causing this? I'm presuming something constantly looping to do the grouping?

Trenloe
December 21st, 2011, 05:14
I confirm a sharp increase in CPU when a character is opened on the Skills page and it is set to "Grouped". When I ungroup the skills, the CPU goes back down.

I am not seeing any memory leak when monitoring resources though. The memory usage increased when grouping, but it remained stable at the increased amount.

For the test, I have put about 45 skills in 5 different groups. I was not doing anything else within FG during the test. On the attached images, FG is using the third CPU.
Thanks for double checking on this. :)

I'm not sure if it's the amount for groups my main character has (15) or something else on top that makes the steady increase in memory. I'm going to do some more testing from the ground up (a new character) and see if there is a threshold or something that I can lay my hands on...

Trenloe
January 10th, 2012, 09:48
We also noticed that when players have their skills grouped and they made a roll with their skill tab open (usual behaviour if you're rolling a skill SM/MM!) there was a lag of a few seconds before their roll would be displayed. This didn't occur when grouping was off.

I've found the culprit - basically, when skills are grouped there is a constant rebuild loop entered into (code in charsheet_skilllist.lua). Rebuild rebuilds the list, which changes the list, which leads to the onListRearranged function being called, which calls a rebuild and so it goes on... Taking valuable FG scripting resources and so leading to slow response of rolls etc (and in my case a memory leak and eventually a crash).

Change the following code in charsheet_skilllist.lua:


function onListRearranged(changed)
rebuild();
end
To:


function onListRearranged(changed)
-- Only rebuild if the skills aren't grouped - avoids constant rebuild loop.
if not isGrouped() then
rebuild();
end
end

Fixed! :)

Ardem
January 10th, 2012, 12:19
Well done, I will make that change in my FRP extention as well.

lachancery
January 10th, 2012, 18:45
Good catch! Have you run tests that some valid calls to onListRearranged while the skills are grouped don't need a rebuild?

Trenloe
January 10th, 2012, 20:23
Good catch! Have you run tests that some valid calls to onListRearranged while the skills are grouped don't need a rebuild?
In the tests I've done, the only thing that I've found is that if you change the "group" of an individual skill then this is not reflected in the grouping immediately - ungrouping then regrouping fixes this issue.

One thing that I have noticed with putting in this fix is that there are now group headings appearing - they never appeared before! Looks like the onListRearranged rebuild loop resulted in the rebuild code never completing and so headings weren't shown.

Perhaps adding a radial menu item to manually rebuild grouped skills might be an option? Or, I just try and sort out what the base issue is... :)

lachancery
January 10th, 2012, 20:47
Sounds like a toggle variable "NeedRebuild" would be the best fix... ;)

Trenloe
January 10th, 2012, 20:52
Sounds like a toggle variable "NeedRebuild" would be the best fix... ;)
Yeah, that's part of my catch all "Or, I just try and sort out what the base issue is..." :)

lachancery
January 12th, 2012, 14:17
It's the last function in the Lua file... Sounds like a hotfix that was put in a minor release with side effects. (I remember another RMC user telling me they used to the category header in their RMC ruleset.)