Wednesday, September 1, 1999

This is the Storable module with shared libraries compiled for
MacPerl.  Shared libraries run only on PPC and CFM68K versions, not
non-CFM 68K versions.

This was compiled with MPW and Codewarrior.  Passed all tests.
I have no 68K machine so I can't test the CFM68K version.  Let me
know of any problems.

Supposedly, Storable doesn't work on CFM68K.  Maybe this version will.

Best installed using cpan-mac, either with the CPAN shell,
or the installme droplet.  From the CPAN shell, type:

   cpan> install CNANDOR/[email protected]

Also, see the MMP page:

   http://pudge.net/mmp/

--
Chris Nandor          mailto:[email protected]         http://pudge.net/
%PGPKey = ('B76E72AD', [1024, '0824090B CE73CA10  1FF77F13 8180B6B6'])

#===================================

                        Storable 0.6
              Copyright (c) 1995-1998, Raphael Manfredi

------------------------------------------------------------------------
   This program is free software; you can redistribute it and/or modify
   it under the terms of the Artistic License, a copy of which can be
   found with perl.

   This program is distributed in the hope that it will be useful,
   but WITHOUT ANY WARRANTY; without even the implied warranty of
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
   Artistic License for more details.
------------------------------------------------------------------------

      *** This is beta software -- use at your own risks ***

The Storable extension brings persistency to your data.
This extension is NOT thread-safe and should not be used by threaded perls.

You may recursively store to disk any data structure, no matter
how complex and circular it is, provided it contains only SCALAR,
ARRAY, HASH and references to those items, blessed or not.

At a later stage, or in another program, you may retrieve data from
the stored file and recreate the same hiearchy in memory. If you
had blessed references, the retrieved references are blessed into
the same package, so you must make sure you have access to the
same perl class than the one used to create the relevant objects.

For instance:

       use Storable;

       $scalar = 'scalar';
       $hash{$scalar} = 'value';
       $ref = \%hash;
       @array = ('first', undef, $scalar, $ref, \$ref);

       &show(\@array);

       store(\@array, 'store');
       $root = retrieve('store');

       print '-' x 10, "\n";
       &show($root) if ref($root) eq 'ARRAY';

       sub show {
               my ($aref) = @_;
               foreach $i (@{$aref}) {
                       unless (defined $i) {
                               print "undef\n";
                               next;
                       }
                       print "$i";
                       print " ($$i)" if ref($i) eq 'SCALAR';
                       print "\n";
               }
       }


when run on my machine produces:

       first
       undef
       scalar
       HASH(0x4001eec0)
       SCALAR(0x4001ee60)
       ----------
       first
       undef
       scalar
       HASH(0x40021fd4)
       SCALAR(0x40017008)

You can see that items are retrieved in memory at some other place,
but the topology of the retrieved data is the same as the original.

I had first written Storable in Perl, but the results were disappointing,
because it took almost 20 seconds to store 200K worth of data. By having
the heart of Storable in C, I can store the same amount of data in about
0.6 seconds. To retrieve the same data, it takes roughly 1.0 seconds,
because you have to allocate objects in memory whereas storing merely
traverses structures.

More accurately, using Benchmark, I get (for a 236802 byte long stored
file):

         Machine       Time to store       Time to retrieve
                        (cpu + sys)           (cpu + sys)
       HP 9000/712         0.61 s                1.02 s
       HP 9000/856         0.33 s                0.39 s

To store/retrieve the "Magic: The Gathering" (MTG) database (1.9 Mb) in
native format:

         Machine       Time to store       Time to retrieve
                        (cpu + sys)           (cpu + sys)
       HP 9000/712         1.95 s                2.19 s

That's roughly 1Mb/s for store and 0.86Mb/s for retrieve.

NOTE: The above figures were valid for Storable-0.5 and earlier. No
similar benchmarking have been made with Storable-0.6 and higher,
which use a different binary image.

Comparison of Storable-0.5@9 and Storable-0.6@3 on a version of
Tom Christiansen's MTG database (1.8 Mb in native 0.5 format, 1.6 Mb
only in 0.6 format) gives:

   Version    Storable Image   "store"    "nstore"   "retrieve"
                Size in Mb     in Kb/s     in Kb/s     in Kb/s

        0.5@9          1.817         801         701         692
        0.6@3          1.526         880         851         870

Kb/s rates refer to the size of the Storable image. Since the image
is shorter with version 0.6, we must normalize the results to compare
relative speed correctly, and therefore measure the overall time it
takes to store/retrieve the same database. We get:

   Version    Storable Image   "store"    "nstore"   "retrieve"
                Size in Mb     in secs     in secs     in secs

        0.5@9          1.817         2.32        2.65        2.69
        0.6@3          1.526         1.78        1.84        1.80

Notice the important gain at retrieval time, due to the fact that we
now use an array instead of a hash table to keep track of retrieved
objects. I have no explaination for the relative speed-up of nstore
operations other than the fact that less tests for "netorder" are made.

To compile this extension, run:

       perl Makefile.PL [PERL_SRC=...where you put perl sources...]
       make
       make install

There is an embeded POD manual page in Storable.pm.

Raphael Manfredi <[email protected]>

Thanks to:

       Jarkko Hietaniemi <[email protected]>
       Ulrich Pfeifer <[email protected]>
       Benjamin A. Holzman <[email protected]>
       Andrew Ford <[email protected]>
       Gisle Aas <[email protected]>
       Jeff Gresham <[email protected]>

for their contributions.