Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[Sheet development]-Troubleshooting slow sheet

January 07 (1 year ago)
Jiboux
Pro
Sheet Author
Compendium Curator

Hello,

The sheet I develop has become a bit slow to open (I.e) 15-30 s with the d20 cursor before the sheet is opened.

I don’t really know how to debug this to find what could be the source. There are a lot of attributes but it also happens for new characters so or in new games.

any suggestion on how to pinpoint some performance issues ? 

January 09 (1 year ago)
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator

are you using any autocalc attributes?

January 09 (1 year ago)
Jiboux
Pro
Sheet Author
Compendium Curator

A handful. Maybe 5. 

Why? Are they notorious for performance issues?

January 09 (1 year ago)

Edited January 09 (1 year ago)
GiGs
Pro
Sheet Author
API Scripter

They are bad for performance, but in the thousands - not for only 5.

Does the slow down happen with new characters immediately you create a new sheet, or does it take time to build up on each sheet?

How many sheets do you have in your campaign (including archived sheets - they don't alter performance)

Can you post a picture of your sheet, and link its code?

January 09 (1 year ago)
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator

They are, but 5 shouldn't cause an issue.

January 10 (1 year ago)
Jiboux
Pro
Sheet Author
Compendium Curator

Thanks all

The code is at 

https://github.com/Roll20/roll20-character-sheets/tree/master/Earthdawn%20(FASA%20Official)

the problem seem to be present on my sandbox or on new games/ characters too

January 10 (1 year ago)

Edited January 10 (1 year ago)
GiGs
Pro
Sheet Author
API Scripter

That looks like a very complex sheet, especially with the way the sheet workers are written. I can't try to diagnose that, it would be way too time consuming.

To find out if the problem is in the sheet workers, put return; at the start of each sheet worker and see if the problem goes away. (Much of the sheet's functionality will stop working, but it'll help you narrow down where the problem is, if indeed it's in the sheet workers).


Or for that matter - just remove everything between the two script lines (make a copy), and see how the sheet's load. If it's now super fast, you know there's something in the sheet workers that is causing an issue, If not, the problem is somewhere in the HTML.

January 10 (1 year ago)
Jiboux
Pro
Sheet Author
Compendium Curator

I’ll run some tests disabling sheet workers and also setting a timer to know their runtime.

One question though: the performance seems really at the opening of the sheet. Do you have any knowledge of impact of server load/ sheet workers or other influences on the loading time of the sheet?

January 10 (1 year ago)
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator

Opening on sheet load would typically be due to a large number of autocalcs. In order for a sheetworker to cause that issue it would have to be exceptionally inefficient.

January 10 (1 year ago)

Edited January 10 (1 year ago)
vÍnce
Pro
Sheet Author

I had a quick look last night at the code and had flashbacks of the Pathfinder Community sheet.  Earthdawn and the PF sheet are like 24K+ lines of sheetworkers alone.  It seemed to me that both the html and workers were, IMO (consider the source...) rather disorganized.  Which does make it hard to isolate/troubleshoot.  I totally get that a sheet that size and age and with multiple authors, would get to this point.  Not knocking the accomplishment but it may be time to bite the bullet and refactor the code? ;-(

January 11 (1 year ago)
GiGs
Pro
Sheet Author
API Scripter

If possible, I'd follow Vince's suggestion and try to rebuild the code.

If sheet workers have lots of sheet:opened events, or a single inefficient worker, it could be the cause - I have seen sheets suffer massive slow down from sheet workers with unneccesary and numerous sheet:opened events that cascade into other functions which then cascade into other functions, and so on.

A cursory glance sauggests that's not the case here, but I'd do a test with all sheet workers removed, just to see if it makes a difference to loading time and at least rule it out as a possibility.

January 11 (1 year ago)
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator

GiGs said:

If sheet workers have lots of sheet:opened events, or a single inefficient worker, it could be the cause - I have seen sheets suffer massive slow down from sheet workers with unneccesary and numerous sheet:opened events that cascade into other functions which then cascade into other functions, and so on.

In my opinion this is an example of inefficient sheetworkers. There's pretty much never a reason why you should have on('sheet:opened') declared more than once in your sheetworkers.

January 11 (1 year ago)

Edited January 11 (1 year ago)
vÍnce
Pro
Sheet Author

Scott C. said:

In my opinion this is an example of inefficient sheetworkers. There's pretty much never a reason why you should have on('sheet:opened') declared more than once in your sheetworkers.

[QUICKLY ZOOM IN]
VINCE (mid-50's, nerdy) Nervously and inconspicuously side-steps out of the room to check on his old code.
[FADE OUT]


January 11 (1 year ago)
Jiboux
Pro
Sheet Author
Compendium Curator

There is in fact one single on:sheet opened worker but that calls for a recalculation of many stuff on the sheet so it may be the cause. I’ll test in that direction.

January 11 (1 year ago)

Edited January 11 (1 year ago)
Scott C.
Forum Champion
Sheet Author
API Scripter
Compendium Curator

The other way the on open worker could cause a startup delay is if it has multiple getAttrs/setAttrs (or relies on cascading setAttrs to trigger other workers)

January 11 (1 year ago)
GiGs
Pro
Sheet Author
API Scripter


Scott C. said:

GiGs said:

If sheet workers have lots of sheet:opened events, or a single inefficient worker, it could be the cause - I have seen sheets suffer massive slow down from sheet workers with unneccesary and numerous sheet:opened events that cascade into other functions which then cascade into other functions, and so on.

In my opinion this is an example of inefficient sheetworkers. There's pretty much never a reason why you should have on('sheet:opened') declared more than once in your sheetworkers.


I agree, but it's very common still.

January 11 (1 year ago)

Edited January 11 (1 year ago)
GiGs
Pro
Sheet Author
API Scripter


vÍnce said:

Scott C. said:

In my opinion this is an example of inefficient sheetworkers. There's pretty much never a reason why you should have on('sheet:opened') declared more than once in your sheetworkers.

[QUICKLY ZOOM IN]
VINCE (mid-50's, nerdy) Nervously and inconspicuously side-steps out of the room to check on his old code.
[FADE OUT]

Hehe don't worry about it. Sheets can survive a lot of less-than-perfect coding. I often have a few sheet:opened in my functions, because they are great for testing, but once the sheet is live, usually you can (and should!) get rid of most of them. Depending on the way the sheet is created, you might still need some. (And yes, they might be inefficent, but if that inefficency isn't visibe to the user, and it's easier to write, it's not a problem IMO.)

January 11 (1 year ago)
GiGs
Pro
Sheet Author
API Scripter


Jiboux said:

There is in fact one single on:sheet opened worker but that calls for a recalculation of many stuff on the sheet so it may be the cause. I’ll test in that direction.

I noticed that. I was speaking more generally but also I didn't examine the worker too closely and it's not uncommon for one worker to actually be multiple workers - when one runs, triggers others through cascading effects. I don't know if that's happening here.