Fix at times broken reactiveness

[giszmo]

Fix at times broken reactiveness

[Giszmo]

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.

[Giszmo]

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.

[snuffyDev]

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

[snuffyDev]

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.

[snuffyDev]

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)

[Giszmo]

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.