bin-prot Vs. stdlib's Marshal

[Francois]

Hello,

Is there a performance comparison of binprot Vs. the Marshal module from the stdlib somewhere?

Is binprot faster?

What happens if you unmarshal (with binprot) a value that you expect to be
of type t but binprot while unmarshalling detects it is of type u ?
Is there an exception I can catch in that case ?

Thanks a lot,
Francois.

[Jeremie Dimino]

On Mon, Jun 1, 2015 at 1:55 PM, Francois <francois.b...@gmail.com> wrote:

Hello,

Is there a performance comparison of binprot Vs. the Marshal module from the stdlib somewhere?

Is binprot faster?

I don't know of a performance comparison, I would assume they are about the same.

 

What happens if you unmarshal (with binprot) a value that you expect to be
of type t but binprot while unmarshalling detects it is of type u ?
Is there an exception I can catch in that case ?

Bin_prot doesn't write the type of the value. When reading a value it simply tries to make sense of the binary data using the function called by the user. You can read the same buffer as values of different types as long as their bin_prot representations are the same. For instance you could read the a buffer containing "\002\065\066" either as the string "AB" or as a tuple of tree integers (2, 65, 66).

However sometimes it can't make sense of the binary data, for instance if you try to read a buffer containing "\042" as a boolean. In such cases the exception [Bin_prot.Common.Read_error] is raised. This exception is described here:

  https://github.com/janestreet/bin_prot/blob/master/lib/common.mli#L106

--

Jeremie

[Yaron Minsky]

If I recall correctly, marshal and bin-prot run at very similar speeds
when writing, but marshal is faster when reading, because it plays
some clever tricks at the GC level to avoid paying the full price for
individual allocations.

y

> --
> You received this message because you are subscribed to the Google Groups
> "ocaml-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ocaml-core+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[David House]

There are other performance implications aside from raw speed as well -- e.g. marshal lets you recover sharing, but bin-prot does not.

That being said, the general opinion is that it's worth paying the price in most cases to use bin-prot. Getting an exception rather than a segfault is nice. Also, and more importantly, it is very obvious which types bin-prot nicely (simply those with a bin_t value), and much less obvious which types marshal nicely -- e.g. I seem to recall there are some gotchas when marshalling lazy_t, which means that every type that uses lazy_t under the hood inherits those weirdnesses, even though that might not be obvious in the interface of that type.

We still use marshal where its superior performance is important, but you have to be very careful. So bin-prot is a good default for most applications. "Predictable semantics > performance, in most cases".