20.02.2016, 03:40
[QUOTE=Slice;3658917]Personally, I link variables to database entries using PVars to store last known values and compare to them every time I do a sync (every 60sec).
The rowid is saved in a PVar so the SQLite overhead becomes as little as possible, since it knows exactly where to perform the update right away, and only update if the value has been changed.
I'll hopefully get around to open-sourcing this code eventually, but for now I'm too busy working on my gamemode.
Wouldnt it be even more economical if you ignore the last value, and just set a "modified"-flag whenever you change one of the monitored variables in the script (or maybe check the old value before setting it)? That way you could save all those "did it change" checks every 60 seconds, just checking that flag should be measureable faster when working with many variables. (and thats actually a question, I dont know if its actually faster. Probably depends on the script/how often it writes duplicate values to variables)
Though I still think that the slow/fast-changing data split is the best way to reduce script- and query-overhead. Variable saving is a pretty static thing, the script very well knows when they change, and the scripter knows how often they change. Adding many runtime checks to detect variable changes that you already know at script compilation can just make things slower.
Sure, its no plug-and-play solution and requires more planning, but most scripts could use more planning anyways.
The rowid is saved in a PVar so the SQLite overhead becomes as little as possible, since it knows exactly where to perform the update right away, and only update if the value has been changed.
I'll hopefully get around to open-sourcing this code eventually, but for now I'm too busy working on my gamemode.
Wouldnt it be even more economical if you ignore the last value, and just set a "modified"-flag whenever you change one of the monitored variables in the script (or maybe check the old value before setting it)? That way you could save all those "did it change" checks every 60 seconds, just checking that flag should be measureable faster when working with many variables. (and thats actually a question, I dont know if its actually faster. Probably depends on the script/how often it writes duplicate values to variables)
Though I still think that the slow/fast-changing data split is the best way to reduce script- and query-overhead. Variable saving is a pretty static thing, the script very well knows when they change, and the scripter knows how often they change. Adding many runtime checks to detect variable changes that you already know at script compilation can just make things slower.
Sure, its no plug-and-play solution and requires more planning, but most scripts could use more planning anyways.