Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^2: Storable( Double size not compatible in Storable) compatible)

by Anonymous Monk
on Jan 08, 2011 at 17:21 UTC ( [id://881243]=note: print w/replies, xml ) Need Help??


in reply to Re: Storable( Double size not compatible in Storable) compatible)
in thread Storable( Double size not compatible in Storable) compatible)

What we really need is 100% reliability, not speed or cleverness.

Is that the royal we, or do you presume to speak for all application writers everywhere?

Replies are listed 'Best First'.
Re^3: Storable( Double size not compatible in Storable) compatible)
by ruzam (Curate) on Jan 08, 2011 at 20:35 UTC

    I think sundialsvc4 should presume to speak for all applications. The only core module we've got to serialize data structures is non transportable and therefore undependable. Core modules shouldn't be a gamble.

    I've been burned myself by 'fozen' data that wouldn't thaw after being transfered to another machine with a different version of Storable. A simple perl update could leave you with a database of unusable data, or a backup file that can no longer be recovered, or in my case it was a move to another server (with a different versions of everything). I'm not going to risk my application like that (again).

    So having learned by lesson I avoid Storable like the plague. Now I 'freeze' data with Data::Dumper (which is core) and 'thaw' with eval. It's messy and awkward and I'm sure no where near as efficient as free/thaw but at least the serialized result is guaranteed to be readable by any version of Perl on any system the data may end up on (or moved to).

    Before it was ever introduced to core, Storable should have been prepared for a future of new features and formats. From the very first 'version change' it should have been purposely defaulted to the most basic universally recognized serialized data format (first version) with caveats to programmers wishing to take advantage of newer features. I would be using it today if I could expect consistent behaviour between versions but as it is I can't rely on it and I can't recommend it. The genie is out of the bottle, you can't fix Storable now.

    Storable has too high a price to pay for anything but fleetingly temporary data. In other words, data that probably shouldn't be 'stored' in the first place. In my books that makes the module a complete fail for the purpose it is (generally) expected to serve.

      If you cannot conceive of any application where store and retrieve performance is more important that inter-platform or even inter-version portability, then you have a very limited imagination.

      Ipso facto, neither you (nor he) are qualified to talk for everyone.

        Then how do you, Anonymous Monk, explain why JSON::XS is considerably faster than Storable in this example:
        # Benchmark use warnings; use strict; use Benchmark qw(cmpthese); use Storable qw(freeze thaw); use JSON::XS; my $hashref = { one => 1, two => 2, three => 3, four => 4, five => 5 } +; my @array = (1 .. 1000); cmpthese( -1, { 'storable-hashref' => sub { my $foo = thaw(freeze($hashref)); }, 'storable-arrayref' => sub { my $bar = thaw(freeze(\@array)); }, 'json-xs-hashref' => sub { my $foo = decode_json(encode_json($hashref)); }, 'json-xs-arrayref' => sub { my $bar = decode_json(encode_json(\@array)); }, } ); __END__
        $ perl -wl bm_storable_vs_json.pl Rate storable-arrayref json-xs-arrayref storable +-hashref json-xs-hashref storable-arrayref 6222/s -- -31% + -84% -99% json-xs-arrayref 8967/s 44% -- + -77% -98% storable-hashref 38280/s 515% 327% + -- -92% json-xs-hashref 501851/s 7965% 5497% + 1211% -- $
        --
        No matter how great and destructive your problems may seem now, remember, you've probably only seen the tip of them. [1]

        If you cannot conceive of any application where store and retrieve inter-version portability is more important than performance then you have a very limited imagination yourself. Perhaps that's why you hide behind anonymity.

        PHP 'serialize' doesn't seem to have a problem with either performance or inter-version portability yet we're stuck the Perl world with a "use at your own risk" core module for what should be a core piece of functionality. Storable could happily live on in CPAN and be an invaluable source for those who need the 'performance' and understand the risk.

        When you don't 'own' the system you're code runs on you have to accept that the world around you may change, sometimes without notice. When that happens, you better not be depending on Storable to keep you running. Of course if you live in a bubble you're free to continue making what ever choices you want.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://881243]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (5)
As of 2024-03-28 20:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found