Bug #58435 for List-Uniq: modifying array being iterated

On Tue Jun 15 21:36:12 2010, user42@zip.com.au wrote: Show quoted text
Indeed, this is what was broken in 0.12. When we spliced in an empty arrayref, the size of the array shrinks but the iterator retains its old value. We then skip over the item that followed the empty arrayref in the original list. I've benchmarked an index and map alternative, and compared their speed to the 0.12 and 0.13 implementations: Rate l-u-0-13-recur index l-u-0-12-recur map l-u-0-13- orig l-u-0-12-orig l-u-0-13-recur 47.6/s -- -4% -16% -35% -51% -62% index 49.3/s 4% -- -13% -33% -49% -61% l-u-0-12-recur 56.4/s 19% 14% -- -23% -41% -55% map 73.2/s 54% 48% 30% -- -24% -42% l-u-0-13-orig 96.4/s 102% 95% 71% 32% -- -24% l-u-0-12-orig 126/s 165% 156% 124% 72% 31% -- The difference between the -orig and -recur variants is that the -recur ones handle lists with arrayrefs more than one level deep: ( 'foo', [ [ 'bar' ] ], [ [ [ 'baz' ] ] ] ) The map implementation lends itself to recursively unwrapping, and once that was in it didn't make sense to benchmark the other implementations without the same logic. So, the change from 0.12 to 0.13 was a 24% performance hit. The map implementation, when compared fairly against 0.13 is more performant but still slower than the published 0.13 release. I'm also concerned that adding the recursion will break existing code, even though I can't imagine a use case in which you want to uniq something containing the stringified representations of listrefs. I've got a 0.14 release ready to go, but I welcome thoughts on the above concerns before pushing it to PAUSE.

"James FitzGibbon via RT" <bug-List-Uniq@rt.cpan.org> writes: Show quoted text
I noticed the current code is "sometimes recursive" :-) use List::Uniq 'uniq'; print uniq('foo',[['bar'],['quux']]); => fooARRAY(0x9572818)quux but could tell if that was meant to be supported or not :). Show quoted text
If uniqueness is by stringizing then it doesn't make much sense to have arrayrefs. And if flattening is done at the toplevel now then you'd be inclined to do it recursively on the same basis. The only thing against flattening might be objects with overloaded stringizing which could be uniqued without wanting to recurse into them. But could have a non-flattening version or option later if anyone wanted that.