-
Notifications
You must be signed in to change notification settings - Fork 483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incremental IDB performance improvements #899
Conversation
} | ||
copyColl.getData = coll.getData; | ||
Object.defineProperty(copyColl, 'data', { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't want lazy deserialization of chunks (a concern of the storage layer) to impact Loki the in-memory database itself more than absolutely necessary, so instead of modifying places that use Collection.data, I modified the Loki object inflation machinery to make Collection.data a lazily-computed property
Update: I've been running this on production for a while now and haven't seen any issues. I have, however, removed the IDB&keys preloading feature. After more extensive performance testing this idea turned out to be a dud. Due to IDB's asynchronous nature, I can't actually hit this optimization reliably enough on production to be worth it (Chrome on production will pull execution of the main scripts synchronously into index.html parsing when it already has it cached, so the main bundle's code won't have a chance to yield to the tiny preload script's IDB callbacks so it can do its job) |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
bad bot |
@techfort gentle nudge :) |
I've had a few more ideas for squeezing more performance out of IncrementalIDB :)
There's usually a pretty big gap between the beginning of index.html parsing and getting to the point with loading the JS bundle that Loki code can begin running. This CPU and network wait could be interleaved with beginning of disk/IDB operations. Now, an advanced user can add a tiny bit of JS into their index.html to preload the idb and list of keys and pass it to IncrementalIDBAdapter to do the complicated work. I've measured a 6-15% improvement (on a very fast computer and testing on a 38MB database - I suspect real-world improvement may be better since triggering the disk operation should warm up IO caches and reduce latency for later reads, while the caches are warm in my tests… I'm not quite sure how to verify this).
In my tests (a real app, with a big, real world account), this yielded a 8% improvement, with a possibility of ~doubling that if I move things around on the app side. This also creates some gaps while app waits for IO, so if I can also take advantage of the concurrency opportunity, the improvement could be as big as 20-25%.
Those are cross-process communication tasks that have to do with sending data between the IDB and main process. However, they're not densely packed, and so CPU utilization is at 60-70% during this period. I'm almost sure this can be improved and this is a quirk of scheduling. I've already improved it a lot with #874, however an opportunity for improvement remains.
I've tried adding more "waves" of requests, changing their timing, changing which key ranges are scheduled to even/odd, reverse, random order… none of that worked :( So no improvement here, for now, but I've committed some tweaks to the key request scheduling code to be more easy to hack and play around in the future