Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

option to use already-existing generated files for flatbuffers and capnp #63

Merged

Conversation

mumbleskates
Copy link
Contributor

No description provided.

@mumbleskates
Copy link
Contributor Author

plausibly this could also be done the other direction, making code regeneration for these a feature that has to be enabled, but is disabled by default. that would probably be fair, and might also serve as a guardrail that makes the tests fail when the generated code has rotted.

@mumbleskates
Copy link
Contributor Author

dang looks like this is true of protoc too but that code isn't checked in. at least that one is older and changes slower

@djkoloski djkoloski merged commit 714b5f8 into djkoloski:master Mar 16, 2024
1 check passed
@mumbleskates
Copy link
Contributor Author

ah dang i thought this was lying cold for a while there. i kinda cleaned this up in my working branch a little more; i have features for "regenerate-capnp", "regenerate-flatbuffers", and "regenerate-prost" that switch the respective codegens on (and committed the prost generated files into the tree to match), so now you can do the whole thing without binaries for protoc, capnp, or flatc at all; meanwhile, CI can still assert that these generated files are up to date

i also added a feature-flag for pprof+flamegraph that works very nicely and easily, at least on linux, that i've been finding useful. and i've added my own encoding library to the bench set, but that doesn't have to be in here until it's cooked a little longer.

you are welcome to any and all of these changes, which i can whip up into coherent pull requests as desired

@djkoloski
Copy link
Owner

Those improvements would be great! No pressure, PR if you would line. And I'm excited to see how your own library stacks up. 🙂

@mumbleskates
Copy link
Contributor Author

I'm excited to see how your own library stacks up. 🙂

tl;dr encoding very similar to protobuf but slightly more compact, with distinguished decoding and canonical output. it's a rewrite of prost; at present it's slightly faster, mostly because i went back and tackled the inlining for a few hours since i remade most of the encoding/decoding stack to use trait-based dispatch.

i have a couple more innovations to apply to the encoding but it needs more work. (would you believe that optimization gets very, very strange when your program is writing bytes to a buffer from the end going backwards instead of forwards? 150% speedups from adding .rev() to a couple iterators, glittering off the shoulder of Orion)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants