Re: [boost] Re: Serialization (Persistence) library draft submission

From: Rainer Deyke (root_at_[hidden])
Date: 2002-03-01 18:14:04

----- Original Message -----
From: "rameysb" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, March 01, 2002 3:14 PM
Subject: [boost] Re: Serialization (Persistence) library draft
submission

> What's the difference:
>
> a) As far as the portability of the data there is no difference.
>
> b) using text is ZERO effort - using XDR or some other scheme
> requires significant programmer effort.

Text may seem to take less effort because the standard library already
handles formatted text i/o.  However, implementing serialization in
terms of formatted text i/o may in fact take more effort than
implementing it from scratch would, especially if the serialized form
is supposed to be native text.  For example, a 'std::string' object
may contain spaces (treated as separator by formatted i/o), newlines
(ditto, and also stored as different character sequences on different
platforms), characters with the high bit set (not part of 7-bit
ASCII), and null characters.  Handling all of these cases probably
already requires more code than my entire portable binary
serialization library.

> c) I doubt that any such scheme is more robust than using the
> functions from the standard library.

Given that a serialization library built on top of the standard
library formatted text i/o is not necessarily simpler than a custom
serialization library, it is also not necessarily more robust.

> d) Execution time.  I would expect be a gain storing/loading to/from
> a native binary mode.  But if you're going to transfer to between
> native and canonical form its going to depend upon how much effort
> was expended in the implementation.  One can't say apriori that
using
> a on particular canonical form is necessarily faster than any other.

A canonical form designed for performance is almost certainly faster
than one designed for human readability in almost all cases.

> e) Archive size.  XDR fills out 32 bit integers to 4 bytes.  In text
> mode any integers less the 100 take only 3 bytes.

I have seen binary formats that store integers less than 128 in a
single bytes.  The tradeoff is that large 32 bit integers may require
5 bytes and the system is somewhat slower and more complex.

>  I don't know if
> XDR handles 64 bit integers but if it does presumable it fills out 8
> bytes per integer.  I would expect that text files are large in
> general but by how much would depend on the particular data.

Note that XDR files are still smaller after compression in most cases.

> portability - text, portable_binary, native

I would switch text with portable_binary here.

> programming effort - text, native, portable_binary

I would place text last here.

> archive size - native, portable_binary, text - application dependant

Native isn't necessarily smaller than portable_binary.

> execution speed - native, text/portable_binary (depends on
> implementation)

Text is almost certain to be much slower.

--
Rainer Deyke | root_at_[hidden] | http://rainerdeyke.com