in reply to Re: Accessing $a and $b of 'sort' across package boundaries
in thread Accessing $a and $b of 'sort' across package boundaries

Is that usage of sort any better/worse/different than something like this?
foreach ( sort gs::long_strings_first($a,$b), @$raw_hash_keys_ar ) { #do_stuff; } package gs; sub long_strings_first { my ($first, $second) = @_; ... }

Replies are listed 'Best First'.
Re^3: Accessing $a and $b of 'sort' across package boundaries
by ikegami (Patriarch) on Jun 06, 2005 at 19:34 UTC

    Yes, I think there's a substantial difference in performance. Feel free to Benchmark.

    Also, doing my ($first, $second) = @_; instead of referencing $_[0] and $_[1] directly adds to the cost. It doesn't give anything in return either, since the names are no more descriptive than $_[0] and $_[1].

      ah. That makes sense -- i figured it was something like that. So is there any difference in these two, assuming the long_strings_first is how you defined it (using $_[0] and $_1 directly)?
      sort gs::long_strings_first @$raw_hash_keys_ar; sort gs::long_strings_first($a,$b) @$raw_hash_keys_ar;
      (first one seems better in appearence, but just curious if any techincal sort-magic difference)

        Actually,
        sort gs::long_strings_first($a,$b) @$raw_hash_keys_ar;
        won't run. You mean
        sort { gs::long_strings_first($a,$b) } @$raw_hash_keys_ar;

        Like I said, I think there's a substantial difference in performance. Let's put it to the test:

        sub implicit { my @array = sort gs::long_strings_first @data; } sub explicit { my @array = sort { gs::long_strings_first($a,$b) } @data; } sub explicit_np { my @array = sort { gs::long_strings_first_no_proto($a,$b) } @data; } __END__ Rate explicit_np explicit implicit explicit_np 606/s -- -1% -49% explicit 610/s 1% -- -49% implicit 1187/s 96% 95% --