in reply to Re: given-when construct unexpected bahavior wit arrays
in thread given-when construct unexpected behavior with arrays
Thanks you all, monks.
I tested the regexp vs "eq" thing in grep (using Benchmark qw/timethis/) and "eq" is waaaaaaay faster than the regexp :D
As for the smart match thing, I found out that too, and it seems quite broken. What I find strange is that the various comments go back even to 2010, and I thought it should had been fixed by now (<-- feel free to fix the verbs in the previous sentence, I usually get lost in hypothetical sentences :P ).
I'll benchmark the last solution proposed by brx, just out of curiosity.
Thank you again!
Cheers.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: given-when construct unexpected bahavior wit arrays
by mantager (Sexton) on Jun 08, 2012 at 06:00 UTC | |
Ok, this is the last testcase:
And the winner is: grep
Bye. | [reply] [d/l] [select] |
by brx (Pilgrim) on Jun 08, 2012 at 07:33 UTC | |
Yep, doing map {"_$_"} @array before each test, in given-when, is not good. But grep works too much because if the first array element matches, you don't need to look others.This is probably the fastest solution :
update: You should also try with an hash %is_in_array | [reply] [d/l] [select] |
by Tanktalus (Canon) on Jun 08, 2012 at 23:10 UTC | |
Oh, don't be silly. Last testcase. Ha! :-) You're missing a whole slew of tests. And, to make matters worse, you're using timethis instead of cmpthese, which makes it so much harder to compare. So, first I'm going to provide, not necessarily the last test case, but the most recent (at the time of this writing) :-) And then I will comment on it, and then provide the output. Read more... (3 kB)
Why 5.16? Because it's the latest. I don't think anything there needs anything more recent than 5.10. So a few things. First off, I'm combining all of the checks into a single run. This basically means we're taking average timings instead of best/worst case. I've also embedded testing the return values here just to make sure we don't end up with a function that is super-fast but wrong. I also capture warnings - since we're trying to do this without provoking warnings, again, testing it helps. This will all slow down each test, but all tests should get the same constant slowdown so the rankings should be the same even if the numbers aren't quite right.
I've moved the array to a global so we also aren't impacted by copying the array around. Again, it's constant, so it's just noise. But this is probably bigger noise than the above :-) So, some additional tests. grep_in_array is your old one. brx_match is brx's suggestion (pretty good one). sm1 is your is_in_array while sm2 is a slight improvement on it (get rid of the underscore, it doesn't help). sh1/sh2 are the same as sm1/sm2 except using a hash base, with sh1 assuming that we're doing many matches against the array (thus the overhead of creating the hash can be ignored) and sh2 assuming we're doing one/few matches (thus the overhead of creating the hash is important). And any is just using List::MoreUtils' XS-based function. It's basically the same as brx' suggestion, but implemented in XS (aka C) instead. Oh, and it's already implemented and isn't subject to cut&paste errors or anything of the like. Okay, now for the output: It should be of no surprise that sh1 completely blew the rest out of the water. The interesting bits are the 4% boost I got from eliminating the unneeded underscore from your original attempt, how much overhead creating the hash has (how slow sh2 is), how much better brx's suggestion is over plain grep (though that's not entirely average - on successful finds, we're weighted toward the first half of the array over the second half), and how much benefit there is (13%) to the XS version of brx's suggestion in List::MoreUtils::any. Moral of the story: use hashes for lookups if you're doing repeated lookups. And if you're not, use CPAN modules. Oh, and maybe I'll try opening the bug report for perl to fix this warning. It's still bugging me. :-) | [reply] [d/l] [select] |