-
Notifications
You must be signed in to change notification settings - Fork 260
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
Indexeddb: more efficient serialization format #3645
Conversation
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.
Looks good. Hoping for big performance improvements.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3645 +/- ##
=======================================
Coverage 84.19% 84.20%
=======================================
Files 256 256
Lines 26600 26600
=======================================
+ Hits 22397 22399 +2
+ Misses 4203 4201 -2 ☔ View full report in Codecov by Sentry. |
I'm going to change the behaviour of `serialize_value`, and we want to preserve the behaviour of this test.
... and make `deserialize_value` handle both the old and new formats. `maybe_encrypt_value` uses a much more efficient representation, so let's migrate to that.
Now that `deserialize_value` returns an `IndexeddbCryptoStoreError`, we don't need these any more.
0440722
to
4d12a78
Compare
The current serialization format that we use for most objects in the indexeddb crypto store is extremely space-inefficient, leading to poor performance and errors (cf element-hq/element-web#27658).
The idea here is to switch to the more efficient format used by
maybe_encrypt_value
. To avoid a huge migration step, we make the deserialization routine handle either format.