Hi Jeen,
Thanks for the feedback.
I would like to improve the current memory store instead, but the way it's built with half the logic in the sail source and the other half in the value factory makes it really hard to pry apart.
My main motivation is to get O(log N) or better lookup. The current memory store is closer to O(N), which I think also impacts the insert performance since it looks like all inserts check with hasStatement() first.
How about this plan as a middle ground:
- Develop new memory store
- Release it as experimental
- Add transaction support
- Beta release with new memory store as default (eg. rename the old one)
- 3-6 months later full release
Adding transaction support would bring it in line with the current memory store, so feature wise users wouldn't loose anything. Do you know of anyone using the transaction support in the current memory store today? Especially the read-committed and snapshot isolation? And for what purpose?
As for a memory store that spills to disk, I think that would be better to design as a memory mapped disk store where you can disable fsync for performance. Does the current disk based store use memory mapped files?
Håvard