in reply to Re^2: Is there a way to reduce Data::Dumper's output size?
in thread Is there a way to reduce Data::Dumper's output size?

Give a try to Sereal.
L*
There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
  • Comment on Re^3: Is there a way to reduce Data::Dumper's output size? (Sereal)
  • Download Code

Replies are listed 'Best First'.
Re^4: Is there a way to reduce Data::Dumper's output size? (Sereal)
by perlancar (Hermit) on Feb 11, 2015 at 16:58 UTC
    Seconded. Apart from being a core module, there's no reason to pick Storable over Sereal.
      there's no reason to pick Storable over Sereal.

      One reason: Sereal doesn't build on windows.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
      In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
        Uh? maybe my Strawberry made my OS no more windows?
        c>perl -e "use Sereal::Encoder qw (sereal_encode_with_object); my $enc +oder = Sereal::Encoder->new(); prin t sereal_encode_with_object($encoder, \@INC),qq(\n\n), qx(perl -v);" =ūrl♥ (+♦&"C:/path/strawberry/perl/site/lib&$C:/path/straw +berry/perl/vendor/lib}C:/path/strawberry/perl/liba. This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x +86-multi-thread Copyright 1987-2011, Larry Wall [..]


        L*
        There are no rules, there are no thumbs..
        Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.

      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.

Re^4: Is there a way to reduce Data::Dumper's output size? (Sereal)
by tkguifan (Scribe) on Feb 11, 2015 at 08:36 UTC
    Interesting because it also incorporates compression.
      It also has compressive properties even without compression. For instance, for structures that contain many repeated keys.