mleku on Nostr: hm, just random thought also the count query method... in previous implementations i ...
hm, just random thought also
the count query method... in previous implementations i think that the actual event data was being pulled and decoded, that just seems silly to me right now, when i can simply count the hits on the filter prefix and return that, which is a much faster operation
also, other random thoughts, after reading about how badger (and dgraph) use a form of ristretto cache system, it occurs to me that i should reformulate the GC cache strategy to use ristretto... would be awesome to cut down a GC pass from 12 seconds for 15gb to like half a second, by using a ristretto algorithm
mmm ristretto... must be time for another
Published at
2024-06-26 15:16:56Event JSON
{
"id": "46df65ef98bf3051aa41ed734bd2d611c9f6ea9af485aa94def28ee70a8df2d7",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1719407816,
"kind": 1,
"tags": [
[
"e",
"410b0a44205bcfd018442bc1631621003e2d46a582bc07f9ef98376e0b5b1b4b",
"wss://nostr.land/",
"root"
],
[
"e",
"410b0a44205bcfd018442bc1631621003e2d46a582bc07f9ef98376e0b5b1b4b",
"wss://nostr.land/",
"reply"
]
],
"content": "hm, just random thought also\n\nthe count query method... in previous implementations i think that the actual event data was being pulled and decoded, that just seems silly to me right now, when i can simply count the hits on the filter prefix and return that, which is a much faster operation\n\nalso, other random thoughts, after reading about how badger (and dgraph) use a form of ristretto cache system, it occurs to me that i should reformulate the GC cache strategy to use ristretto... would be awesome to cut down a GC pass from 12 seconds for 15gb to like half a second, by using a ristretto algorithm\n\nmmm ristretto... must be time for another",
"sig": "387878b9092f67452ffdb89b9fe5219ae95e6c2a619e913626ffd797afe3becae19e42b2c4af82a5e1a05e4b43c8623f36549d252d499ee7c67da14d049f1609"
}
