http://qs321.pair.com?node_id=213148


in reply to The Cost of Nested Referencing

I don't agree code with multiple indices is necessary hard to read, and using an intermediate reference is clearer. Something like:
$data {$host} {$user} {$process} += $time_used;
is in my opinion far more clear than:
$host_ref = $data {$host}; $user_host_ref = $host_ref -> {$user}; $proc_user_host_ref = $user_host_ref -> {$process}; $proc_user_host_ref += $time_used;
The former clearly shows you are collecting data, per host, per user and per process. The latter is just a mess, and you quickly run out of sensible variable names.

If you have cases where $var {key1} {key2} {key3} becomes unclear, you either have to redesign your datastructure, or need to find better key or variable names.

That using a reference to an inner structure is a win in your benchmark is clear, as you don't have to redo some calculations. But you cannot do that always - you can only do that if you access the same keys repeatedly. Often, the keys used are variable, and will differ from iteration to iteration.

Abigail

Replies are listed 'Best First'.
Re: Re: The Cost of Nested Referencing
by shotgunefx (Parson) on Nov 15, 2002 at 14:30 UTC
    I don't think they are necessarily hard to read at all.

    but...
    foreach my $k ( sort { $self->{state}{inputs}{expected}->{$a} <=> $ +self->{state}{inputs}{expected}->{$b} } keys %{ $self->{state}{inputs +}{expected} } ){ # do stuff }
    can be a little hard on the eyes. I'm certainly not advocating that everyone use refs when working with HoH's. The main point of the post was that going deep gets slow quick and that I'm suprised that in certain cases, it isn't optimized away. Perl seems to do everything else for me so I was suprised.

    On occasion, I've used hashes simply as a way to group variables.
    %hash =( headers=>{data}, data=>{ "huge hash" } );
    One such instance was a quick and dirty search tool. It was a HoH with a huge amount of entries. If by using a simple assignment, I can get a 15% speed up when iterating through large data sets, I think it's worth doing.

    "That using a reference to an inner structure is a win in your benchmark is clear, as you don't have to redo some calculations. But you cannot do that always - you can only do that if you access the same keys repeatedly. Often, the keys used are variable, and will differ from iteration to iteration."

    I'm not sure what you mean by this point. Care to clarify?

    Thanks,
    -Lee

    "To be civilized is to deny one's nature."
    update
    Do you mean $h{$thiskey}{$thatkey} ?, but even then, orderly traversals are a fairly common thing, so in those cases where time is an issue, I still think it's a good thing to know.
      My post contains an example of using variables as keys.

      Abigail

Re: Re: The Cost of Nested Referencing
by lestrrat (Deacon) on Nov 15, 2002 at 19:21 UTC

    on linear code like that it may make things hader to read, but I don't see what's wrong with

    my %hash = ( ..... ); foreach my $key1 (@keyset1) { my $inner = $hash{$key1}; foreach my $key2 (@keyset2) { print $inner->{$key2}; } }

    instead of

    my %hash = ( ..... ); foreach my $key1 (@keyset1) { foreach my $key2 (@keyset2) { print $hash{$key1}{$key2}; } }

    That doesn't sacrifice too much in readability, I think

      They're both far too verbose.
      for my $subhash (@hash{@keyset1}) { print $subhash->{$_} for @keyset2; }
      or if you really only have a single statement in there, even print @{$_}{@keyset2} for @hash{@keyset1}; You can be efficient and readable all at the same time.

      Makeshifts last the longest.

        I *personally* would rather stay away from

        statement if condition statement for(@list)

        ...because that way I'm less likely to be bashed by others claiming that (my) perl code is unreadable ;)

      Beauty is in the eye of the beholder, but I find the latter far more readable that the former.

      Abigail