They are not theorical man... Efficient garbage collection without the dev even thinking about it is literally the whole reason Java exists. Every app uses those things all the time. For many apps, the cache is just the list objects for the feed itself. We do some crazy things on top of it, but I don't expect anyone to have to do it for smaller apps. The rest is just regular loads using Nostr filters.
Login to reply
Replies (2)
you’ve chosen to optimize in an area I’m avoiding entirely. I am just happy i don’t have to deal with garbage collection and inefficient use of memory.
You are not avoiding it. You are making an entire DB to mimic garbage collection because you don't have garbage collection. I fell like I am the one avoiding everything you went through to make it.
And I am happy you are doing it. I really do. All I am asking is this discussion is to provide performance indicators that allows us to compare the complete performance with other stacks.
If I compare my cache with your DB already in memory, the performance is exactly the same. Mine might be slower because it is full thread safe for 1000s of reads and writes in the same millisecond. But that's it. Basically its the difference between B+ trees vs hash tables.
So, if I follow 500 people and use 5 Nostr apps, do you truly think duplicating 500 profiles in memory on each of those apps is an "efficient" use of memory?