-
Notifications
You must be signed in to change notification settings - Fork 3.3k
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
Why flatbuffers instead of capnp? #2
Comments
See the Benchmarks section in the docs:
|
Besides the comment above, the two are not that similar. FlatBuffers combines the flexibility of Protobufs with the efficiency of Cap'n Proto, in a sense a best of both worlds approach. Which is better depends on your use case. |
Useful for comparisons https://kentonv.github.io/capnproto/news/2014-06-17-capnproto-flatbuffers-sbe.html |
Merge pull request #2 from amoldeshpande/master
Fix build against C++03 stdlib; merge upstream
@gwvo Could you explain how flatbuffers is more flexible? I'm having a hard time understanding (at an API level) how flatbuffers improves on cap'n'proto. For my use case, perf differences between the two are negligible. Perhaps an example of a common scenario which flatbuffers handles better than Cap'n'proto could shed clearer light on this? |
FlatBuffers, like Protobuf, has the ability to leave out arbitrary fields from a table (better yet, it will automatically leave them out if they happen to have the default value). Experience with ProtoBuf has shown me that as data evolves, cases where lots of field get added/removed, or where a lot of fields are essentially empty are extremely common, making this a vital feature for efficiency, and for allowing people to add fields without instantly bloating things. Cap'n'Proto doesn't have this functionality, and instead just writes zeroes for these fields, taking up space. They recommend using an additional zero-compression on top of the resulting buffer, but this kills the ability to read data without first unpacking it, which is a big selling point of both FlatBuffers and Cap'n'Proto. So Cap'n'Proto is either not truly "zero-parse", or it is rather inefficient/inflexible, take your pick. |
Thanks for the clarification! I'd read this, but wondered if there were other aspects to consider. My use case is for representation of a graph of small nodes, so there aren't any god objects likely to grow extensively (and since I'm using it as IPC and not over the wire, space is not a concern). |
If you're use case is small, simple, non-evolving objects, you're likely not going to notice much difference between the two. In that case you're better of picking which you prefer based on API, features, platform/compiler/language support, or whatever is important to you. |
Fixed bug with negative hex constants (2).
Revert "flatbuffers master merged to hunter branch"
With the recent fixes, it makes this repository compatible with Bazel flag `--incompatible_disallow_old_style_args_add` Progress towards google#2 Closes google#5 googlecloudrobotics/core#5 ORIGINAL_AUTHOR=Laurent Le Brun <laurentlb@gmail.com> GitOrigin-RevId: 0e362c40d00ceada2e301ad620c336c6346337f1 Change-Id: I96a7a45b4383d053e9177f05ad5870646a83827d
This pulls in some Bazel compatibility changes (google#2). Change-Id: I525f0edb7e15099a7a6df7850124b0bbcbf610d2 GitOrigin-RevId: 4cb1717b3cc487bedefda51a0edcac26205f3c1e
- use .to_list() instead of iterating - use depset() constructor instead of .union() See google#2. Change-Id: I9bb75fe638e029f7b55dd3647c414e64f5c86066 GitOrigin-RevId: 857882805e01de0e880ed2154b6b39e1b7f28394
The old `.proto` provider will be removed in a future Bazel version. See google#2. Change-Id: Id53260a1855f078d510779ad66cf23f9ede09a61 GitOrigin-RevId: f822b73d7c9cf0810f7cae6be529a8d09122dd9e
Due to a change in how the dependencies work, we need to be careful to load go_repository from deps.bzl, not def.bzl: bazel-contrib/rules_go#1933 Additionally, Gazelle 0.17.0 seems to find the dependencies in src/.gopath, so I've added a gazelle:ignore directive for them. At the same time, I've added the path to .bazelignore, so that Bazel doesn't try to build or run files in there. This pulls in some Bazel compatibility fixes (google#2). Change-Id: Ic215ca30c0e6bb438e8fff134e439e4e4a032879 GitOrigin-RevId: 8c7708b9a97f5ab6a34db5aa36dc1be9b63d2fbd
This pulls in a Bazel compatibility fix. See google#2. Change-Id: Ib59f363c154a5132f5c641eea4cc5f683135c5b0 GitOrigin-RevId: 89269a1251f72c9b0b7bea61ff74c1b50c7fe282
For historical reasons, Bazel has two directories for generated files, although a future version of Bazel will remove the genfiles directory: bazelbuild/bazel#6761 Currently, rosmsg() copies all the source files (*.msg, *.srv) to the output directory, so that the directory structure matches the needs of ROS's codegen tools. It uses a hacky way of finding the paths to the transitive dependencies within the output directory, which includes a direct reference to genfiles. By using output_to_bindir=True, we can avoid the direct reference. Fixing the hack would involve rewriting the rosmsg() macro to use a rule, which wouldn't be too hard but might break compatibility. See google#2. Change-Id: Ibae3451e1329e397329089aa6796c5477789c788 GitOrigin-RevId: e38ef5d044984c858b7e1d21867347e1bb0d28a8
Create msbuild.yml will add the folders to Gerome-Ysmael
…s-to-mydevice Merge pull request #2 from portintegration/master
* Fix nightly no_std * Fix nightly no_std
You mention memory efficiency as the main selling point of flatbuffers. However, capnp already exists, with zero copy "serialization," and a range of compelling features (RPC, etc). Still you saw the need to build flatbuffers, which means this library either (a) does something capnp doesn't, or (b) beats capnp in some respect. Could you please describe somewhere what this rationale is? Why should someone pick flatbuffers instead of capnp?
The text was updated successfully, but these errors were encountered: