in reply to ASP and Storable woes

Before you go to the trouble of hacking Storable, why not give Data::Dumper a try? It certainly won't be as fast as raw Storable, but it almost as certainly will be faster than Storable -> uuencode. As a bonus, it will probably be more compact than Storable (as long as you set $Data::Dumper::Indent to 0). And it shouldn't give you any high-bit characters.

-dlc

Replies are listed 'Best First'.
RE: (dchetlin: Data::Dumper) Re: ASP and Storable woes
by gregorovius (Friar) on Sep 29, 2000 at 09:49 UTC
    Thanks, dchetlin!

    The mechanics for doing it with Data::Dumper are the following: 

      my %h = (key1=>'value1',
        key2=>{key3=>'value3'});
 
  my $stringy = Dumper \%h;
  {
    no strict 'vars';
    %h = %{eval($stringy)};  
    die"$@" if $@;
  }

    [download]
    That eval there takes 0.25 seconds on my 17,000 elements hash. This is much better than the 0.47s for uudecoding and thawing of the same hash, but still five times more than the 0.05s of thawing that I would get if that peculiar $Application object worked right.
[reply]
[d/l]
RE: (dchetlin: Data::Dumper) Re: ASP and Storable woes
by princepawn (Parson) on Sep 29, 2000 at 12:59 UTC
    I just read the Data::Dumper docs. Indent has no effect on the correctness of the output. Only how readable it is to the human eye.

    Purity and Terse are more related to allowing nested seralized data to be reconstructed. See the section "Configuration Variables or Methods" for the gory details.

[reply]
      Er ... what I said was:

      • As a bonus, it will probably be more compact than Storable (as long as you set $Data::Dumper::Indent to 0).

      I didn't mention correctness, I mentioned compactness -- with $Indent set, you get an extremely compressed string that will more often than not be smaller than Storable's binary encoding of the same data.

      The drawback is of course that Storable will always be faster.

      -dlc

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom