Subnostr

i see no need for using a general purpose json parser for a very specific protocol, as a general purpose implementation, if it's not generated code, it's going to be slower due to reflect and if it's generated code the complexity of the generated code will account for cases that are not present in the actual use case

the json parsing i have inside the event, envelopes and filters are custom made for the task and are as lazy as possible so they are fast, and the code is easier to debug

i wrote a cut down version of bytes.Buffer that has special elements for recognising and cutting out strings, escaping that is specified in NIP-01, and it can scan through a whole object inside an envelope without parsing just looking for the bounds of the object and pass it to a more detailed process

Reply to this note

Please Login to reply.

Discussion

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

i'm kinda focused right now on hitting a milestone target in the next two weeks on the project i'm building with this but in two weeks i think i can be confident enough to pop it out by itself, since if it reaches that target it covers everything required for a paid relay with arbitrary storage back end interfaces

i haven't developed any other than the badger driver for the database but i intend to build one for another k/v store: https://github.com/akrylysov/pogreb

the rationale for using this one is that it is very fast at retrieval, way faster than anything else, and my intended use case of the database in my relay is for caching front end for a distributed data store backend, so most of the workload is actually read side, and that's something i know because i watch the activity of clients using my relay and they pull soooo much data over and over again, and pogreb gives fast speed without as high a memory use cost for the use case