Suggestion

instead of saving the all variable in a single csv file (by default),
what if the variable is saved on a folder where it will stored based on its name?
something like
{a} -> ./plugins/skript/variable/_.csv
{a::#} -> ./plugins/skript/variable/a.csv
{a::b::#} -> ./plugins/skript/variable/a/b.csv

where # is any alphanumeric text

and as a failsafe if for example _.csv is overloaded then it would create a another file which will be named 2.<name>.csv

and can be backup as a zip file

Why?

reason:

• to avoid queueing too much variable to a file which lag the server
• to lessen amount of variables getting corrupt from accidents
• to remove a list without starting a server
• not needed to tamper the database option to separate variables

downside:

• reworking how variable are load
• may slowing down variables
• file conflict will happen if they use "." on the variable name

Other

i would suggest to add this as a experimental feature and having a original feature running at the same time.

upsides and downsides are not the only ones there maybe more.

Agreement

• I have read the guidelines above and affirm I am following them with this suggestion.

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.

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

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.