> You might argue that if users kill apps all the time, there is more memory for nostrdb pages to stay live, but what happens if 3-5 apps have embedded nostrdb at the same time? Are they all going to stay? What happens if it is 10-20 apps using nostrdb.
From what i understand the page cache maintains an LRU cache of pages (4096 byte slices of the db). Even if you have lots of nostrdbs, the OS can intelligently evict pages that haven’t been touched in a while.
This is the great thing about virtual memory mapping, the OS should make sure to have pages that are frequently accesses available while pages that don’t get touched that often can be reclaimed.
You don’t need all of the data in a DB all the time, the OS will make sure there is enough memory for apps that need it based on access patterns.
The OS should always use all available memory for the page cache, on my desktop arc (zfs thing) is using 16gb right now.
Login to reply
Replies (2)
Also the comparison to citrine is weird. This is not a replacement for a local relay, it’s for a high performance in-process relay. Thats a different thing.
You can’t have local relays on iOS. Think of this as the nostr version of indexeddb in web browsers.
I agree it is different. But we can do local relays on Android. So, to me the question really is what is the DB that the local relay is using and how to make that relay load from disk as fast as possible. Sure, the apps will still have their own cache, but it can be an in-memory only cache. If the relay is fast, the apps don't need do manage any event storage by themselves.