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

Why flatbuffers instead of capnp? #2

Closed
jbenet opened this issue Jun 17, 2014 · 7 comments
Closed

Why flatbuffers instead of capnp? #2

jbenet opened this issue Jun 17, 2014 · 7 comments

Comments

@jbenet
Copy link

jbenet commented Jun 17, 2014

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?

@jbenet jbenet changed the title Why would someone use flatbuffers instead of capnp? Why flatbuffers instead of capnp? Jun 17, 2014
@julienschmidt
Copy link

See the Benchmarks section in the docs:

Cap'n'Proto promises to reduce Protocol Buffers much like FlatBuffers does, though with a more complicated binary encoding and less flexibility (no optional fields to allow deprecating fields or serializing with missing fields for which defaults exist). It currently also isn't fully cross-platform portable (lack of VS support).

@ghost
Copy link

ghost commented Jun 17, 2014

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.

@jbenet
Copy link
Author

jbenet commented Jun 18, 2014

Useful for comparisons https://kentonv.github.io/capnproto/news/2014-06-17-capnproto-flatbuffers-sbe.html

@ghost ghost closed this as completed Jun 19, 2014
@ghost ghost mentioned this issue Sep 5, 2014
ghost pushed a commit that referenced this issue Jun 17, 2015
ghost pushed a commit that referenced this issue Jun 17, 2015
Merge pull request #2 from amoldeshpande/master
ghost pushed a commit that referenced this issue Jan 19, 2016
biddisco pushed a commit to biddisco/flatbuffers that referenced this issue Mar 16, 2016
Fix build against C++03 stdlib; merge upstream
@lilith
Copy link

lilith commented Apr 27, 2016

@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?

@ghost
Copy link

ghost commented Apr 27, 2016

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.

@lilith
Copy link

lilith commented Apr 28, 2016

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).

@ghost
Copy link

ghost commented May 20, 2016

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.

ghost pushed a commit that referenced this issue Aug 26, 2016
Fixed bug with negative hex constants (2).
ahundt pushed a commit to ahundt/flatbuffers that referenced this issue Sep 25, 2016
Revert "flatbuffers master merged to hunter branch"
vglavnyy added a commit to vglavnyy/flatbuffers that referenced this issue Aug 29, 2018
unintellisense added a commit to unintellisense/flatbuffers that referenced this issue Jan 8, 2019
unintellisense added a commit to unintellisense/flatbuffers that referenced this issue Jan 8, 2019
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
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
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
This pulls in some Bazel compatibility changes (google#2).

Change-Id: I525f0edb7e15099a7a6df7850124b0bbcbf610d2
GitOrigin-RevId: 4cb1717b3cc487bedefda51a0edcac26205f3c1e
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
- use .to_list() instead of iterating
- use depset() constructor instead of .union()

See google#2.

Change-Id: I9bb75fe638e029f7b55dd3647c414e64f5c86066
GitOrigin-RevId: 857882805e01de0e880ed2154b6b39e1b7f28394
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
The old `.proto` provider will be removed in a future Bazel version.

See google#2.

Change-Id: Id53260a1855f078d510779ad66cf23f9ede09a61
GitOrigin-RevId: f822b73d7c9cf0810f7cae6be529a8d09122dd9e
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
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
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
This pulls in a Bazel compatibility fix. See google#2.

Change-Id: Ib59f363c154a5132f5c641eea4cc5f683135c5b0
GitOrigin-RevId: 89269a1251f72c9b0b7bea61ff74c1b50c7fe282
comius pushed a commit to comius/flatbuffers that referenced this issue Nov 5, 2020
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
portintegration referenced this issue in portintegration/flatbuffers Dec 27, 2020
Create msbuild.yml will add the folders to Gerome-Ysmael
portintegration referenced this issue in portintegration/flatbuffers Dec 27, 2020
…s-to-mydevice

Merge pull request #2 from portintegration/master
ofirm93 pushed a commit to ofirm93/flatbuffers that referenced this issue Apr 20, 2021
CasperN pushed a commit that referenced this issue Oct 19, 2022
* Fix nightly no_std

* Fix nightly no_std
bulentv pushed a commit to zdrealityhub/flatbuffers that referenced this issue Oct 21, 2022
* Fix nightly no_std

* Fix nightly no_std
This issue was closed.
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

No branches or pull requests

3 participants