variable local storage improvement about skript

[Moderocky]

A user could have thousands of different list::variations::like:this, potentially multiple for every::%player%::who::joined the server.
This could create hundreds of thousands of files, all of which take up extra disk space (headers, metadata, inodes, file tables, etc.) and will slow down the system incredibly.
Not to mention there's no difference in the amount of data you're loading, except that it's having to access hundreds of different places, so it'll be significantly slower than it is currently.

[corrupteddroid]

yes but no.

{player::%player%::scores} can be {player::scores::%player%} but it would be harder to clean up using "clear {player::%player%::}"
if we exclude that idea leaving {player::scores::%player%} as the format then and it may became more efficient if each storage file are loaded one by one. if one of the storage fail for example scores then {player::scores::} will not work until its fully loaded

[Moderocky]

yes but no.

No, I'm telling you it won't.

to avoid queueing too much variable to a file which lag the server

You are still doing exactly the same number of variable writes, you're just doing them in a dozen different places. We append entries in the CSV for run-time writes so it doesn't mean there would be any less to write.

It's more costly to store and load the same data across hundreds of separate files than in one, because we still need to store/load all of them at the same time. The only difference is we're having to make hundreds of additional requests to the filesystem.

This could be conditionally faster if a user has a very specific variable setup that we can parallelise into about ~10 containers during saving and loading, but if that isn't the case it'll just become worse than what exists currently. Even with parallel loading there is a very low limit of how many things you can do at the same time (particularly when these all have to be delegated to the operating system to arbitrate).

If you want to save time, use a more efficient variable storage system (e.g. database). Most of the issue is just the inefficiency of the editable CSV format.