gardencmp
Failed to load coValue from peer / loading a huge coList
Error:
Failed to load coValue from peer
Object { coValueId: "co_z4RZerBy5kg6QnwfEi6N5po1nMC", peerId: "indexedDB", peerRole: "storage" }
I used the example from guided tour and created 4.000 issues under one project with a worker process under node
When I scroll through the issues of the project to the end of the list. The app hangs every xx lines, loads some data, even when all data was synced. On the first scrolls I see many Failed to load coValue from peer errors in the browser console and sometimes it is not possible to get all items.
My second problem is related to the worker process under node which fails to delete the issues:
pnpm jazz-worker --project-id=co_XXXXXXXXX --delete
("jazz-worker" is defined in packages.json)
From my logging it looks like the worker is not able to get the coList project.issues synced. With small number of items up to 100 it works without any problem.
The process to create X issues is:
pnpm jazz-worker --project-id=co_XXXXXXXXX --count=4000
Hi @aheissenberger,
Thank you for reporting this issue. I was able to repro and it seems that this is due to sync timeouts. I will investigate further.
@4rknova This is not a fix of the underlying problems in jazz. Using paging with max 50 items per page is a work-a-round by avoiding handling more rows where 5.000 rows is a very very low number and no problem for react. I tried the same with gunjs and had no issues with blocked react render queue and no errors at all.
@aheissenberger
Well, can't disagree with you.
We just wanted to give you a quick solution, but if you really want to load this much data all at once, you will have to wait for a proper fix to land.
Honestly we still have alot to optimize, so we will surely get there in no time!
Thanks again for the repro, will use it as a first performance goal 😄
@aheissenberger
An update on this issue.
We have shipped some optimizations with the latest Jazz version (0.13.11) and it is now possible to load the list.
Without changing the code on your example the list loads gradually and the first render time is actually acceptable.
When using $each: true to load the full list before render it takes around 90s on my laptop, mostly because the deepLoading algorithm isn't really optimized.
We will probably work on that soon, because it really needs some love.
Going to keep you posted!
This is a huge improvement to before as the blocking of the browser event loop is gone and it reliable loads all Data.
Thank you!
Released the optimizations on the subscribe in Jazz 0.13.18 and now the list of 4k issues loads in around 3s when using { $each: true }
We can still do better as there are other low-hanging-fruits on the performance side to puck (loading from storage can and should be instant) but we are not anymore in a bad shape.
@aheissenberger if it's all good on your side we can close this issue.