Author of pycapnp here. For those too lazy to click through, pycapnp is tremendously slower than C++/Rust. The equivalent benchmarks take about 20-50x as long.
What's more interesting to me is comparing it to other Python serialization libraries. I've been meaning to update the benchmarks with some popular ones (msgpack, thrift, and the built-in json module are at the top of my list). If there's some interest, I'll go ahead and post it to HN when I'm done.
You're probably thinking of the original version of Cap'n Proto's schema parser, which was written in Haskell. The code generation step that it helped to handle is not a part of this benchmark.
As far as I know, nobody has written a Cap'n Proto serialization runtime for Haskell yet.
Comments
I wonder if it'd be instructive to have a Ruby or Python benchmark too, just to show how much you gain by using a lower-level language.
See this thread on the Cap'n Proto mailing list for some idea of how well Python does on this benchmark:
https://groups.google.com/forum/#!topic/capnproto/BDpV6WEG5B...
Author of pycapnp here. For those too lazy to click through, pycapnp is tremendously slower than C++/Rust. The equivalent benchmarks take about 20-50x as long.
What's more interesting to me is comparing it to other Python serialization libraries. I've been meaning to update the benchmarks with some popular ones (msgpack, thrift, and the built-in json module are at the top of my list). If there's some interest, I'll go ahead and post it to HN when I'm done.
I'd certainly be interested!
Curious, how feasible would it be to simply call into existing C/C++ libraries from python instead of writing it in pure python?
Pycapnp is not pure Python. It wraps Cap'n Proto's C++ dynamic API. See http://kentonv.github.io/capnproto/otherlang.html#supporting... .
Thank you!
Keep in mind pycapnp is a wrapper of the c++ lib, so you aren't seeing all of the lower-level language gains in the comparison.
It depends which implementation get compared.
If the standard implementations get used, that any strong typed language with ahead of time compilation to native code will win hands down.
Now if RubyMotion or PyPy are part of the benchmark, maybe they can achieve good enough performance.
Love that. I am still hoping for a Ruby Implementation in Rust once Rust hit 1.0
Why? (Genuinely curious...)
I wish we could compare the old Haskell version to the C++ and Rust versions as well.
You're probably thinking of the original version of Cap'n Proto's schema parser, which was written in Haskell. The code generation step that it helped to handle is not a part of this benchmark.
As far as I know, nobody has written a Cap'n Proto serialization runtime for Haskell yet.
See http://kentonv.github.io/capnproto/otherlang.html .
Quite good results, given that Rust is still quite a young language.
Agreed. Also, less (/no?) memory related bugs counts for something too.
i'd be surprised if there wasn't a decent amount of bugs still in the standard library
There's probably not too many memory safety bugs in the standard library, most of it is "safe" code (i.e. Rust code without any `unsafe`).
(That said, there probably are some `unsafe` blocks that were not written with enough care, etc.)
For the "catrank" case, could you use std::str::raw::from_utf8 to skip the utf-8 validity check?