Performance optimization: make PREFERRED_TRIM_SIZE configurable #36
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Why
I faced issue that if my initial
YDoc
starts from 3-5Mb this can lead to serious memory usage by IndexedDB on each update.First steps
I investigated a lot of discussions, issues, forks etc. Understood each situation in detail.
What a problem?
People wait that this just should works good. But everyone has their own expectations. I think each tool need more detailed documentation about such processes.
After bunch hours of learning code and other situations I realized that inside
y-indexeddb
exists logic for optimization memory usage. It triggers under certain condition. You just need to reach it. But not so simple... 🫤PREFERRED_TRIM_SIZE
On each document update this constant used for checking whether IndexedDB exceed to this limit. If yes - do trim.
Trimming - reduce data usage of IndexedDB.
PREFERRED_TRIM_SIZE
equals500
_dbsize
equals records count in IndexedDB.By simple words:
So, for triggering data trimming I need to do
500
YDoc updates to update IndexedDb500
times respectively.Okay, whats next?
If your update size is 12b it really doesn't matter - 12b * 500 = 6000b - 6kb
But if your update is 4Mb here is interesting - 4Mb * 500 = 2000Mb - 2Gb 🥲
And yeah, this is expected behavior.
So what do you want man? 🤔
I think the best approach would be to make
PREFERRED_TRIM_SIZE
configurable. For example decrease it value from500
to100
. (4Mb*100 = 400Mb)Main idea that each can configure
PREFERRED_TRIM_SIZE
by their data size.If you know that your updates big - you decrease
PREFERRED_TRIM_SIZE
for triggering trimming earlier.So this PR:
PREFERRED_TRIM_SIZE
configurable fromIndexeddbPersistence
instance via passing options objectExample:
@dmonad, I would be glad if you can provide feedback for my contribution!
Peace ✌️