GNU bug report logs - #57079
29.0.50; Performance of seq-uniq is not very good

Previous Next

Full log

Message #28 received at 57079 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 57079 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: Re: bug#57079: 29.0.50; Performance of seq-uniq is not very good
Date: Tue, 09 Aug 2022 20:36:34 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  57079 <at> debbugs.gnu.org
> Date: Tue, 09 Aug 2022 19:23:10 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> delete-dups is destructive.  You can copy the list first, of course, but
> >> seq-uniq should be much faster than it is.
> >
> > How much faster?  Using copy-sequence and delete-dups is 7 times
> > faster here than seq-uniq and twice faster than
> > gnus-delete-duplicates.
> 
> I didn't claim that seq-uniq will be faster than copy + delete-dups; I
> just said that it's unnecessarily slow.

But the above means that using seq-uniq with TESTFN nil is going to be
unnecessarily slow from the get-go.  People shouldn't use seq-uniq if
they don't need a non-default TESTFN, because much faster
implementations exist.

IOW, since this bug is about speed, not anything else, I think making
seq-uniq faster when TESTFN is nil isn't the right solution, the right
solution is to point out that seq-uniq's purpose in this case is not
to be a Speedy Gonzales.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.