Nostr

Ask me questions directly and I can answer them.

The code creates a set of query specs from a filter -- i.e. if the filter specifies an author and a kind, we return one spec for traversing the 'pubkeyKind' index at the specified key range, if the filter specifies 4 authors and 2 kinds, then we return 8 specs for traversing the 'pubkeyKind' index in all these different combinations.

Then we gather all the results in a heap and take them in sorted order and return them through the channel.

The heap part can probably be improved, let me know if you have something better. Maybe sacrifice a little bit of strict ordering to get some performance?

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

also, it's a series of if/else if/else if/else if

that would have been better structured as a switch, for a start, for the clarity of the top level

there is three cases if i remember correctly, where two go to two options and one goes to three

some comments explaining the reason why this order of actions would have helped a lot

i will explain it, just as i have also explained the binary formatting of your code in other work

and i won't thank you because decoding bad code is harder than writing it.

Reply to this note

Please Login to reply.

Discussion

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

tech debt is no joke

you'll understand it when you get older

fiatjaf 1y ago

It's not a series of if/else if/else if whatever. It's as straightforward as it can be, all the verbose bloat comes from badger.

Or maybe you're talking about the part that takes stuff from the heap thing and so on. But that part has a lot of comments.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

no, it is not polished code if you have 3 or more conditions and you don't use a switch and you don't explain why there is several conditions... there is a total of some 9 or 10 separate pieces of logic in there and you string them together with if else if else if if if else if else if else

that's why there is a switch, it is much more concise and exact for 3+ cases

no, i'm talking about the function that i linked to, not the heap stuff... i'm not a fan of the heap you used either, making a simple priority queue is not that hard to write with concrete types and no need for all those type assertions

you don't get the benefit of badger if you think making keys with indexes in them, which is not how you do it with most other KV stores, is "bloat"

they are a separate log and so reading them is cheaper, and adding them doesn't require any work on the much bigger value log

badger is the best KV store in the field of data storage and you think it's bloated

unfortunately, that seems to be a common misunderstanding, and everyone goes on about LMDB but that shit is just a fucking giant swap file and depends on kernel to do its magic, and it still has write amplification problems, you add keys you have to restructure the values

not the same as badger, you can write keys all day long and it never has to compact the value log!