If the starting point is DD then that is certainly true. Strictly speaking there are /still/ certain use cases where Storable is a better choice. For instance in the cases where *exact* struct level equivalence is required. But that level of accuracy goes out the window as soon as almost /any/ serialization package is used, and in %99.99999 of use cases this level of equivalancy is unnecessary. (Consider subtle things like dualvars and whether you care if they round trip "properly", most use cases would not care.)
On the other hand, there are a number of good reasons to choose Sereal: it produces smaller output faster, and it is not vulnerable to the "Storable upgrade trap", which can be serious blocker preventing upgrading perl in "continuous availability" environments.
Storable always outputs the latest version of the protocol, and the encoder and decoder are inseperable from each other, so you cannot run mixed versions of perl in an environment that shares data using Storable. If you do, when a new perl writes it will write something unreadable by all the older perls/Storables. So while the new Storables will be able to read data written by the old perls, the new perls wont be able to *write* something that the old perls can read. (Maybe this has been fixed since the last time I paid close attention to Storable, but I doubt it.)
Avoiding this trap was one of the primary motivations for writing Sereal. We looked at improving Storable, but there was no spec for it, so it would have been a lot of work to make it do what we needed. So we designed Sereal to deal with all the issues we had with Storable. By migrating all our Storable data to Sereal we escaped the upgrade trap and at the same gained speed and size efficiencies across the board.
In reply to Re^5: Is there a way to reduce Data::Dumper's output size? (Sereal)
by Anonymous Monk
in thread Is there a way to reduce Data::Dumper's output size?
by tkguifan
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |