Re^3: Accessing $a and $b of 'sort' across package boundaries

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].

Comment on Re^3: Accessing $a and $b of 'sort' across package boundaries Select or Download Code

Replies are listed 'Best First'.
Re^4: Accessing $a and $b of 'sort' across package boundaries by davidrw (Prior) on Jun 06, 2005 at 19:49 UTC
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;` [download] (first one seems better in appearence, but just curious if any techincal sort-magic difference)	[reply] [d/l]
Re^5: Accessing $a and $b of 'sort' across package boundaries by ikegami (Patriarch) on Jun 06, 2005 at 20:54 UTC
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: Read more... (849 Bytes) `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% --` [download]	[reply] [d/l] [select]