Nostr Web Client

I try not to be a language maxi. To me C is pretty close to synonymous with the binary/assembly which is my attraction. I'm pretty dumb so being able to quickly understand/map my code to hardware is helpful I think. I stick to strict C89 features (or lacktherof). When I write it, I can pretty easily imagine what that stack and registers will look like. I spend at least one pass before a release looking at an assembly dump. I obviously don't spend too much time on it because modern compilers are 1000000 times better than I will be at this, but I would consider myself a defensive C programmer.

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

yeah, i'm similar but i choose Go, and so i also have to deal with sometimes working around the default memory management strategy (for this reason i switched event data structures to use raw bytes where by default common idiom is to use immutable strings (which cause your app to generate tons of garbage and can't be zero-allocation or zero copy)

Reply to this note

Please Login to reply.

Discussion

ChipTuner 1y ago 💬 1

I did the same with C#. Almost everything that requires more than a few bytes handles alloc/free on umanaged memory from high performance allocators that can be configured at startup. You will notice a class called VNString. An immutable heap string that is very similar to the string type in C# but stored on the unmanaged heap and 0 copy slices.

https://github.com/VnUgE/VNLib.Core/tree/develop/lib/Utils/src/Memory

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

yeah, it's a huge cost, managing garbage, and for Go the immutable string is definitely a liability for fast network message processing... i mean, switching to mutable bytes (not immutable string) sped JSON processing almost to equal to raw binary!