Improve settings system performance

[jlillis]

Is your feature request related to a problem? Please describe.
Currently, the settings system functions are slow. Per discussion here it would be good to improve this within mtasa-blue to benefit all resources rather than just caching within the admin resource.

Describe the solution you'd like
Some form of caching or other code improvements to improve the performance of the settings system functions.

Describe alternatives you've considered
1 - Do nothing: see context below
2 - Cache settings per resource: will result in duplicated resource code and limited benefits.

Additional context
I bench marked 10,000 calls to get at 60ms which is a bit slow. However, I believe it is unlikely that get will be called 10,000 times in a single frame. This suggests that alternative 1 (do nothing) would also be acceptable.

[Pirulax]

The problem with caching is that we'd need to keep track when the file gets modified.
One possible solution is to always read the file, and check if the checksum has changed. If it has, then re-parse the file. But all this takes a lot of time, obviously.
I personally feel like outside modification of the settings should've not been supported.

[jlillis]

Strictly speaking, I don't think outside modification of settings is currently supported. The wiki states (emphasis mine):

The settings system allows you to store and retrieve settings for future use, or provide server administrators with an easy way to configure your resource without modifying any files.

Settings can be modified in two ways - either by scripts or by the server administrator using the console.

The most common use case for administrators using the settings system is to change the setting from within the admin panel (technically a "script" in the context of the wiki quote). I think this and changes via console are the only use cases that need to be supported. Dropping the ability to modify settings files during runtime doesn't count as "backwards-incompatible" as that functionality was never added intentionally or guaranteed to exist.

[Pirulax]

Ah, youre'right.
In that case @botder wrote a new system a few years ago, he sent it over to me, but it was never incorporated into MTA, for whatever reason.
Anyways, its possible to load the entire settings system into memory, it fine. CPU > RAM, because servers can have a lot of RAM, but single threaded CPU is limited.