Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re: Perl Idioms Explained - keys %{{map{$_=>1}@list}}

by Aristotle (Chancellor)
on Aug 04, 2003 at 20:18 UTC ( #280788=note: print w/replies, xml ) Need Help??

in reply to Perl Idioms Explained - keys %{{map{$_=>1}@list}}

Just as memory hungry, still not order preserving, and still broken with regards to undefined values, but faster approach:
my %seen; @seen{@list}=(); my @uniq = keys %seen;
And if you want to wrap it up without "leaking" lexicals:
my @uniq = do { my %seen; @seen{@list}=(); keys %seen; };
This approach does not (explicitly) iterate - more of the data structure setup work is done implicitly by perl.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re: Re: Perl Idioms Explained - keys %{{map{$_=>1}@list}}
by Juerd (Abbot) on Aug 05, 2003 at 07:00 UTC
      undef is not documented to work on slices. That command should probably generate at least a warning.

      Caution: Contents may have been coded under pressure.
        perlfunc's entry for undef suggests this behavior on slices, if one squints:
        Undefines the value of EXPR, which must be an lvalue... Saying undef $hash{$key} will probably not do what you expect...
        That is, taking "undef EXPR" as (usually) equivalent to "EXPR = undef", the behavior is sensible, even expected. At any rate, a warning seems inappropriate, as this feature is long-standing:
        $ perl -le 'undef @h{qw|a b c|}; print "$]: ", join " ", keys %h' 5.00404: a b c
Re: Re: Perl Idioms Explained - keys %{{map{$_=>1}@list}}
by Jenda (Abbot) on Aug 06, 2003 at 14:24 UTC

    This actually seems to be slightly quicker than the grep based solution:

    Benchmark: timing 100000 iterations of broquaint, grep_seen, aristotle +, juerd... broquaint: 25 wallclock secs (21.62 usr + 0.01 sys = 21.63 CPU) @ 46 +22.99/s (n=100000) grep_seen: 12 wallclock secs (11.55 usr + 0.00 sys = 11.55 CPU) @ 86 +60.26/s (n=100000) aristotle: 10 wallclock secs ( 9.05 usr + 0.00 sys = 9.05 CPU) @ 11 +044.84/s (n=100000) juerd: 9 wallclock secs ( 8.66 usr + 0.00 sys = 8.66 CPU) @ 11 +543.35/s (n=100000)
    my @list = qw/a b c d d a e b a b d e f a erti wen udfgn wei sdej usdjdh iu t k a b b b b a a a a c d f e f s r s gkl h u s y t d s w s d log u log ds/;

    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
       -- Rick Osborne

    Edit by castaway: Closed small tag in signature

      Yep. As I said, it does not iterate on the Perl side. The pertinent nodes in optree are only ever seen once, and the loop is implicit in the execution of that single op. With all other approaches, the pertinent ops have to be dispatched and executed as many times as there are items in the list.

      In fact, the keys %{{map{$_=>1}@list}} approach needs to first iterate over all elements of @list for the map, building a list as it goes, then build another list for keys.

      In contrast, the @uniq = grep ! $seen{$_}++, @list; approach only builds a list once, while iterating over the elements of @list.

      And of course as already explained, undef @seen{@list}; @uniq = keys %seen; just builds a single list - without iterating at all.

      Makeshifts last the longest.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others chanting in the Monastery: (7)
As of 2021-12-06 09:34 GMT
Find Nodes?
    Voting Booth?
    R or B?

    Results (32 votes). Check out past polls.