Nostr View

mleku @mleku - 1mo

#realy now has a tested working garbage collector functionality, previously it was scratched in from previous work but i wrote a revised tester that fits in with the new schema of everything in realy it is the afternoon and i have a little work to do now to update an Internet Computer #layer2 eventstore implementation, that allows relay operators who somehow like ICP to run a relay that uses a sharded blockchain database to store events it is of course of interest to said shitcoiners, and good for them, and you know what i mean when i say good for you my life would be misery without my bad jokes so also, good for you, directly but it's also nice for people who want to run a plain and simple realy instance, now you can contain the event storage with typical low/high water mark cache management options and your specified gigabyteage with just one little .env file and did i mention that it's also got the fastest JSON encoder and event store database out there? some day in the future, when i have more time on my hands, i will build a test rig that lets me really see realy head to head with #strfry and i'm almost certain that realy is not gonna be far behind it, and probably, on a parity hardware basis, better good for hoyte and his C++ lunacy

0
0
3

mleku @mleku - 1mo

no, the database when you build any kind of data storage system you have to deal with limitations, let's say you rent a VPS with a 25Gb disk, and that gives you about 18gb of free space to store your relay's events so, now, with #realy - you can set your maximum database size at 18gb and depending on how fast it adds new events, set your high and low water marks to trigger purging of events that nobody has looked at in the longest time reduces the cognitive burden of managing a relay, and also lets you optimize the cost of running one

1
0
3

mleku @mleku - 1mo

also just want to mention rust and its bastard children do have garbage collectors the biggest difference (aside from OOP data model) between #golang and #rust is that rust forces the programmer to explicitly state where a variable is in scope, the so-called "escape" problem Go's GC uses a heuristic to try and (conservatively) pick memory allocations that are stale or definitely not in scope whereas Rust forces the programmer to stipulate when a variable is in scope this lets Rust apps squeeze a little more performance, in the same way as C++, at the expense of high complexity of compilation (read memory and time cost for developers) and a longer test/edit cycle (because of that) the margin is no more than about 5% it's not worth it when you consider that it doesn't actually matter that much, 5% better performance, when it costs $5/month for the basic VPS and that means 10 cents saving versus if you wrote your shit in Go, which saves you 5% on the cost of your programmers

1
0
3

mleku @mleku - 1mo

nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnvv9hxgtcpzamhxue69uhk6mr9dd6jumn0wd68yvfwvdhk6tcqyqwj7rk9fcy077x8d5hhukdy3t248qxay8wkz20qzqu58qp929pvkmququn

1
0
3

mleku @mleku - 1mo

also this is why the inventor of #nostr is a #golang programmer because fiatjaf already understands the fact that Go apps are faster and less painful to build

0
0
3

mleku @mleku - 1mo

it keeps an record of the last time each event was returned to a client, and it removes the ones that were least recently returned to clients

1
0
3

mleku @mleku - 1mo

i tried to justify not keeping this record but ultimately, events have their own "created timestamp" so that's there anyway, and you could maybe implement a GC that just purges by oldest created_at but that would not really be practical for a lot of use cases

0
0
3
Showing page 1 of 1 pages