Are sheetworker js object stored more than once?

Hello Roll20

Working on a character sheet that include some rather large orbjects for holding data on ability scores and the like. I have a player who was worried that running multiple sheets in a game (up to 150) would eat up all his RAM on his PC.

So If I have a large object defined in my sheetworker javascript do I need to check that it is not already defined in the javascript engine, or does Roll20 handle that for me?

Here is an example:

I have added this object in my script section simply as

<script type="text/worker">
    const strengthTable = {};
    ... // a lot of static data
</script>

Do I need to wrap this object in an if statement to avoid loading it twice if it is already loaded? Ie.

<script type="text/worker">
    if (strengthTable === undefined) {
      const strengthTable = {};
      ... // a lot of static data
    }
</script>

Or does Roll20 handle that for me, in the way they handle sheet worker code?

My gut feeling is that Roll20 handles the load, because when ever I use the log, Ie.

console.log();

I only ever see my log messages once, when the game opens and then not again, indicating that all sheetworker data is loaded once per game, and not once per sheet.

Roll20 should handle this for you.

Each character sheet runs in its own sandbox, I think (if there's a bug in the code that takes one sheet down, other sheets keep working). So with multiple sheets running, and each loading their own code, its possible in theory to have memory and CPU issues. But honestly, I cant imagine the size of objects you'd need to be storing in sheets before that becomes an issue.

If you're running up to 150 sheets in a game, and trying to have them all open at once, you will almost certainly hit other issues before anything on the sheet worker side causes problems. Roll20 does not handle lots of characters all that well. Each character can have hundreds or thousands of attributes on them, and the number of attributes in a game is one of the first things that causes problems. Its frequently advised that you should only have characters in a campaign that you intend to use - don't try to have a monster manual of hundreds of monsters for example. Also, if you have spellcasters, try to only have the spells they have actually prepared, not all the spells that can use, because spells can cost a lot of attributes.

These sheets cause lag even if you never open them - just by existing in the campaign. Conversely, sheet workers are only loaded when the sheet is actually opened (I believe), and so will never be the resource-hog that attributes are.

GiGs said:

Roll20 should handle this for you.

Each character sheet runs in its own sandbox, I think (if there's a bug in the code that takes one sheet down, other sheets keep working). So with multiple sheets running, and each loading their own code, its possible in theory to have memory and CPU issues. But honestly, I cant imagine the size of objects you'd need to be storing in sheets before that becomes an issue.

If you're running up to 150 sheets in a game, and trying to have them all open at once, you will almost certainly hit other issues before anything on the sheet worker side causes problems. Roll20 does not handle lots of characters all that well. Each character can have hundreds or thousands of attributes on them, and the number of attributes in a game is one of the first things that causes problems. Its frequently advised that you should only have characters in a campaign that you intend to use - don't try to have a monster manual of hundreds of monsters for example. Also, if you have spellcasters, try to only have the spells they have actually prepared, not all the spells that can use, because spells can cost a lot of attributes.

These sheets cause lag even if you never open them - just by existing in the campaign. Conversely, sheet workers are only loaded when the sheet is actually opened (I believe), and so will never be the resource-hog that attributes are.

Thank you GiGs!

This means that things works as I expect them to :)

I was unaware of the problem with attributes. I will keep that in mind in the future when developing sheets. Simply reuse of attributes instead of adding more / references to other fields

I was unaware of the problem with attributes. I will keep that in mind in the future when developing sheets. Simply reuse of attributes instead of adding more / references to other fields

I dont think there's a problem with the number of attributes on a single sheet - you can have hundreds or thousands of attributes on a sheet. it's just when you have many character sheets, you are pushing things, because each one multiplies the number of attributes. I think (I am guessing) the problem is that every attribute (probably including attribute copies) requires a call to roll20's data servers to get the value it represents, and this is done for every attribute in every sheet in the campaign, whether the sheet is open or not.

(If so, there's an obvious target for optimisation on roll20's part, though obviously i have no idea how difficult that would mean and there must be a reason they havent done it. One example of the complexity of the problem: when running a macro that targets an attribute on another character, the system needs to be able to access that attribute value. Maybe having it loaded in the character sheet makes that more efficient. But I'm just speculating.)

If you have really small sheets with not many attributes, you can have more more characters before you'll see issues, and with really havesheets (like the D&D or pathfinder sheets) you'll see problems earlier - unfortunately those tend to be the ones where GMs want to have massive character lists (which makes sense).

Many campaigns, especially those with lighter sheets, will never see issues because of this.