Fix at times broken reactiveness
Giszmo opened this issue · comments
Especially at startup, Dexie DB hooks appear to not fire, sometimes for up to 20s at a time.
The event writer reports to usually take 100ms to write 500 events and takes 100ms pauses between single-threaded writing but something is happening on that thread that makes those 100ms writes take up to 20s during which all nostroid reactivity breaks down.
My suspicion is that something CPU-intensive kicks in that slows down everything or some other DB reading/writing affects the event writer. Could it be the Garbage Collector? I certainly produce a lot of garbage all the time everywhere. This needs to be debugged. Where is the biggest potential to avoiding garbage?
As the issue is very erratic - it might be one write that takes long and all before and after are smooth - I don't see how to "throttle when it gets too slow". For less powerful machines, 500 puts at a time might take too long, so maybe there is room for some mechanism that keeps the median bulkPut below 100ms but that's another issue.
Apparently events get downloaded repeatedly whenever the SharedWorker starts. Observed from the relay side "53000 events were sent in 153ms", which definitely is too big a burst for the client.
While investigating this I noticed a lot of the memory allocations come from Dexie. I’m also investigating what improvements, if any could be had, from using a RWLock to have a way to control the reads and writes
After taking some time to ‘reset’ my brain, I’ve managed to achieve (in my opinion, after testing it for a good amount of time) a more consistent experience.
Demo: https://nostroid-test.vercel.app/
Currently preparing to commit my changes to my fork, and create a PR once I clean up a couple things and pull in the latest commits.
The heap allocations still isn’t great, which I have a few ideas on how to minimize them, but the bulk of them come from Dexie and the crypto libs it appears.
For reference, here’s the bar graph on this repos deployed build.
Both profiles were taken starting from the very start of the page render, to ~1-1.5 mins after it stops getting new events (around 15k)
Your deployment indeed feels smoother.
The nostr library I think is part of the problem as switching it for another one had a dramatic impact on performance but that other one wasn't ready for all the features yet. It might be worth giving it another try.