When you call set on the file system store, if its in synchronous mode, it updates the in-memory cache, then, if there is a pending write already queued up, it just returns. Otherwise, it schedules a write to disk of the cache in 30 seconds time (or whatever you've configured its flush interval to).
That means:
- if this is the first write to context you've done since the last flush to disk, then the write to disk will happen in 30 seconds time.
- if you'd done a write to context 28 seconds ago (that was itself the first write since the last flush), then the value you've just written will be saved to disk in about 2 seconds.
So the flush interval does not mean each write to context you do will be saved 30 seconds later. It means each write you do will be written to disk at most 30 seconds later, but it won't write to disk more than every 30 seconds.
Currently it will write the whole context for that scope to disk each time (ie the entire context for a flow or node). There is an item on the back to improve this by moving to a log-based system where only updates are written to a rolling log - or some other similar method.
It's largely up to which style you prefer. I don't think there is going to be much difference in raw performance unless you're trying to handle 10000s of operations a second.
If I had to guess, I'd say getting the whole object, then addressing the sub property directly then writing the whole object back would be mildly more efficient as you can let native JavaScript do the property lookup in the object, rather than have our code parse your property expression and dig into the object.
Having said that, in a future where we only write updates to disk rather than the whole object, it would be more efficient to call set with just the property you are updating so we only write that, rather than the whole object.
None that I can think of immediately.
