Performance Penalties: ES3 vs referencing methods

[Coldwynn]

I'm developing a team sport game with as many as 35 characters per team with 22 players (11 per side) on the field at the same time. Each character has 8 primary attributes and a growing number of derived secondary attributes. It's a lot of data to keep track - especially as the game moves from scene to scene and script to script.

The standard way of passing data along is with the use of ScriptableObjects and/or binding variables to gameObjects and referencing those gameObjects from another script (perhaps with Find and Tag). However, I've found it easier (and more sensible) to ES3.Save whole arrays and Dictionaries at the end of each script and ES3.Load those same data at the start (OnEnable) of each new script.

I've noticed, however, as the program has grown, that it is taking a second or two longer to move from script to script. I'm still roughly in the first 10% of the game, so I worry that this build up of hard drive access will make the game unplayable.

Does anyone have experience with load times increasing like this? Should I get off the ES3 habit and use more of the standard data transfer methods?

[Joel]

Hi there,

Typically to ensure data persists from scene to scene you would simply use static variables. However, if you do wish to use Easy Save for this purpose and you're seeing performance drop, have you followed the Improving Performance guide?

https://docs.moodkie.com/easy-save-3/es ... rformance/

All the best,
Joel

[Coldwynn]

I neglected to mention that the properties/attributes of each player character are user defined or adjustable throughout the course of gaming, so static variables will not work. Also, with the 30+ characters having the same kind of attribute (strength , say), I have to find a way to both address each character's strength uniquely, and also be able to mass-address (like in a for loop) all the strength attribute. So Dictionary<string, double> (and sometimes Dictionary<string, double[,]>) seemed to be the only way ... hence, the massive saves and loads.

No, I dd not know about caches. I will look into it. Thanks.
Does the memory allocation have to be predefined or is the speed gain purely from having the predetermined locale?

[Joel]

Hi there,

The memory doesn't have to be predefined. The performance benefit comes from being able to bundle multiple IO writes/reads into a single write/read. You will only see a significant benefit if you are writing multiple keys to the same file.

All the best,
Joel

[Coldwynn]

What exactly does "multiple keys to the same file" mean?

For example, I have a bunch of arrays:
QB = new double[,] { { 5, 6, ....}, { 2, 3, ... }, ....;
OLT = new double[,] { { ....;
...

which are then packed into a Dictionary:
playerStats.Add(currentTeam + "QB", QB);
playerStats.Add(currentTeam + "OLT", OLT);
...

which then uses ES3 to save
ES3.Save<Dictionary<string, double[,]>>("playerStats", playerStats);

Does the single key ("playerStats") which refers to a dictionary holding multiple keys count as "multiple keys to the same file"?

[Joel]

Hi there,

Your example would write a single key to the file: "playerStats". If you made another ES3.Save call with a different key, this would write another key to the file.

All the best,
Joel

[Coldwynn]

Thanks for the clarification.

One more question before I try to implement the cache routine: What controls whether multiple ES3.Save go to the same file? As long as the saves are not separated by other commands, as long as the saves are within the same method, within the same script, within the same scene? Or is there just one file for the entire program?

Wait ... I just reread your post, that can't mean that each key has its own file, can it? Because then I don't see how you can have one file with multiple key entries ...

[Joel]

Hi there,

If you don't specify the filePath parameter of the ES3.Save method then it will save it to the default file specified in Tools > Easy Save 3 > Settings. If you specify the filePath parameter, it will use that file.

For more information please see the Getting Started guide and the Settings, Paths and Locations guide:

https://docs.moodkie.com/easy-save-3/ge ... me-or-path
https://docs.moodkie.com/easy-save-3/es ... ons/#paths

All the best,
Joel

[Coldwynn]

Thanks for your time. I'll get to work and report back in a week or so on whether there is a performance gain.

[Coldwynn]

I'm happy to report that the performance gains were quite significant and readily observable.

A small note: the manual isn't clear that the command line:

//set a cache for ES3 Saves/Loads
var settings = new ES3Settings(ES3.Location.Cache);

had to be written into, not only every script, but into every method that contains a save or load command. Since I had peppered the entire game with multiple save and load commands (using ES3 to transfer data between scripts and scenes), I had a heck of a time tracking down every method that had an ES3 procedure.

Still, the performance gains were well worth the effort.

Thank you. Easy Save continues to be an indispensable tool.