joshsny
Suggest having manual mode, so setting in loops can be done at once.
You can get even better results by having a manual mode, where the programmer can call .set but it doesn't actually persist yet (just puts it in the cache). Then, when the programmer manually calls .persist (or whatever), the library can use the .setMany function.
This is especially effective in loops. Example of it is here: https://classroomtechtools.github.io/ObjectStore/
The programmer could also build up their own properties and set them at the end of the loop, but that means making another object, and maintaining that.
Hi brianysmurf 👋 Thanks for submitting the issue!
I like the idea of having a manual and automatic mode. The problem of increasing write efficiency is a more challenging trade off of simplicity and speed than read efficiency.
For a lot of scripts that don't have long running functions and are guaranteed to return something quickly (e.g. Add-Ons), wrapping all your return calls in a persist function and then having set use the in memory cache would allow for only making one write to the Properties store per execution. This can be really helpful when writes are spread across different functions in the code.
The downsides to this however are:
- Have to remember to persist at each return.
- Doesn't work well if the execution fails, since some of the writes are lost.
In my own real life examples, persisting stuff in the Cache (instead of in memory) on each set call and then saving it at the end significantly slowed performance (but provides other benefits like being able to share properties between executions without writing to Properties) and using a setMany call allowed for much better speed. In fact, I often see similar speeds between writing to Properties and writing to the Cache.
What is your experience of this with ObjectStore?
If I am worried about executing a block of code that might fail, I use a context manager for that.
https://github.com/classroomtechtools/ContextManager