Re^2: Challenge: CPU-optimized byte-wise or-equals (for a meter of beer)

There is an important flaw in your test. The entire 100_000 character string is composed of the exact same characters. There ARE NO NULLS most of the time! ~~That's only a flaw if the data that the algorithm is meant to work with has a different composition than the test data.~~

~~Since we don't know this, we can only assume that dragonchild provided us with test data that looks like the "real" data.~~

Update: I finally understood what you are saying... the testing was flawed, really.

Perl 6 in German

Comment on Re^2: Challenge: CPU-optimized byte-wise or-equals (for a meter of beer)

Replies are listed 'Best First'.
Re^3: Challenge: CPU-optimized byte-wise or-equals (for a meter of beer) by SuicideJunkie (Vicar) on Sep 12, 2007 at 14:48 UTC
If that were true, then this would be close to the ultimate function: `sub supertest { my $s1= shift; if (substr($s1,1,1) ne chr(0)) { return $s1; }else{ return shift; } }` [download] Seems pretty silly to me for that to be the case ;)	[reply] [d/l]
Re^3: Challenge: CPU-optimized byte-wise or-equals (for a meter of beer) by Corion (Patriarch) on Sep 12, 2007 at 14:54 UTC
On the "other" test set, my approach fares far more within my expectations, but here the number of elements returned seems to become significant over the number of string joins: `Rate split1 substr1 map_split subst map_spl +it_join using_str_bit_ops_and_tr split1 1.74/s -- -94% -100% -100% + -100% -100% substr1 30.5/s 1650% -- -93% -94% + -94% -96% map_split 455/s 26002% 1392% -- -13% + -15% -34% subst 520/s 29765% 1607% 14% -- + -3% -25% map_split_join 534/s 30577% 1653% 18% 3% + -- -23% using_str_bit_ops_and_tr 692/s 39604% 2169% 52% 33% + 29% --` [download] So, you will need to always benchmark with real data! ;)	[reply] [d/l]