Table Memory Usage

[mattekure]

I found a Wild Magic effect table online that I've implemented into my FG campaign. The table is unfortunately, quite large, containing 10,000 entries. While this makes for some great random fun, I've noticed that it does vastly increase the memory used by FG. Before loading the table to roll, FG us using a steady 800MB, but just opening the table made it balloon to 1.8GB.

So, my question is simply, is there a way to set it up so it doesnt take as much memory? would be be more efficient memory wise to split up the table into subtables, say with 1000, 500, or 100 entries each, and have a single table that rolls onto the subtables?

[shadzar]

breaking 1 table into multiples would only take more memory as you would have more to load each separate table. if you wanted to b break it up and save memory, you wold need a main table to roll on, and each subtable would be another module you can load and unload the previous table as you go.

Roll on Table A, get results, close Table A, open Table B, roll on Table B, close Table B, open Table C... etc...

[LordEntrails]

Huge random tables are sexy, but how many unique crits do you need? I mean 1000 is probably more than you will use in several years of gaming. Though their is always the chance to duplicate... I would just break them up into tables of 100 or 1000 and then just open one of the tables that motivates you that session.

[mattekure]

Huge random tables are sexy, but how many unique crits do you need? I mean 1000 is probably more than you will use in several years of gaming. Though their is always the chance to duplicate... I would just break them up into tables of 100 or 1000 and then just open one of the tables that motivates you that session.

I've been playing around with it today and I think I got something that works. I have 100 tables, each with 100 entries, so the full 10,000 posibilities, and a single master table that rolls to select which sub-table to roll from.

For the memory usage, I had the task manager loaded and it appears that the tables are not loaded into memory until the first time they are opened/rolled. So by breaking it up this way, it will only load 2 tables, the master with 100 entries, and single sub-table with 100 entries that gets rolled. This caused my RAM usage to only increase by 30Mb when loaded, compared to increasing by 1GB with my previous version of all 10000 in a single table.

I have made this into a module, but I am waiting for permission from the author before posting it.

[shadzar]

so what happens when it starts rolling on other tables after the first one? does the same problem happen with 20 of the smaller tables open and memory starts getting used exponentially again? os is the Wild Magic, jsut picking from one sngle table per play sessin, and next sessions you roll to pick the table to roll on for that session?

[mattekure]

so what happens when it starts rolling on other tables after the first one? does the same problem happen with 20 of the smaller tables open and memory starts getting used exponentially again? os is the Wild Magic, jsut picking from one sngle table per play sessin, and next sessions you roll to pick the table to roll on for that session?

I just did some testing on that. Before I begin rolling, the RAM holds steady at around 600MB, after rolling about 40 times, the memory had risen to 650MB, so not bad at all. Typically in my games, the wild magic effects may come up 2-3 times a session, rarely more. So this works just fine for it.

The way I have it working, it is a table entry, that calls another table to roll. So the Wild Magic table, rolls a 1d100, and lets say it rolls a 67. That will then roll on the "Wild Magic 67" table which has 100 possible entries. The next time it rolls, it rolls a 34, so it rolls again on the "Wild Magic 34" table. So if you were to just keep rolling hundreds of times, it probably would increase memory by a lot, but I dont see that as very likely.

[Trenloe]

It's possible that the FG instance is releasing the table memory once the second table has been rolled on and no longer needed.

I'd recommend trying this on a player instance too - the player side handles resources differently, sometimes opening them in the background, even if they haven't been opened yet (it's a known issue). So, my concern is that all of these tables may overload a player instance, even though it works OK on the GM side.

[mattekure]

It's possible that the FG instance is releasing the table memory once the second table has been rolled on and no longer needed.

I'd recommend trying this on a player instance too - the player side handles resources differently, sometimes opening them in the background, even if they haven't been opened yet (it's a known issue). So, my concern is that all of these tables may overload a player instance, even though it works OK on the GM side.

Good point, I just ran it with a player connected and did 100 rolls. The player side was hardly affected at all, it went from 496Mb, to 510Mb, then after about 20 seconds, it dropped back down. It seems like it handles releasing the memory better. After 100 rolls, the GM side went from 600MB to 700MB

[Trenloe]

Cool. Nice one! :)

[Bidmaron]

Did the player try to roll or were you just doing it on the GM server instance? Did you share the tables with the player client?

[mattekure]

Did the player try to roll or were you just doing it on the GM server instance? Did you share the tables with the player client?

My original tests I did not have the player roll anything. Normally I wouldnt have the player roll, I roll as the GM and have it output to a story entry, then I can share it as needed.

However, I did just test it as player. I loaded it up and shared it to the player, who rolled 50 times. The memory went up about 40 Mb for a little bit, but after 30 secs or so, it went back down to normal.

[Bidmaron]

Good to know!