Performance optimization: make PREFERRED_TRIM_SIZE configurable#36
Open
frontend-sensei wants to merge 2 commits intoyjs:masterfrom
Open
Performance optimization: make PREFERRED_TRIM_SIZE configurable#36frontend-sensei wants to merge 2 commits intoyjs:masterfrom
frontend-sensei wants to merge 2 commits intoyjs:masterfrom
Conversation
…nce via passing options
dmonad
requested changes
Oct 3, 2023
Member
dmonad
left a comment
There was a problem hiding this comment.
Looks good. But please make the suggested changes.
Author
|
Feel free to ping me, if something can be improved 😉 |
Author
|
@dmonad It's ready for your review |
Author
|
@dmonad Any updates? |
Author
|
@dmonad By any chance, do you have an update? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
YDocstarts 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-indexeddbexists 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_SIZEequals500_dbsizeequals records count in IndexedDB.By simple words:
So, for triggering data trimming I need to do
500YDoc updates to update IndexedDb500times 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_SIZEconfigurable. For example decrease it value from500to100. (4Mb*100 = 400Mb)Main idea that each can configure
PREFERRED_TRIM_SIZEby their data size.If you know that your updates big - you decrease
PREFERRED_TRIM_SIZEfor triggering trimming earlier.So this PR:
PREFERRED_TRIM_SIZEconfigurable fromIndexeddbPersistenceinstance via passing options objectExample:
@dmonad, I would be glad if you can provide feedback for my contribution!
Peace ✌️