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

Previous Next

Full log

View this message in rfc822 format

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

> Cc: 57079 <at> debbugs.gnu.org, stefan <at> marxist.se
> Date: Tue, 09 Aug 2022 20:36:34 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> 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.

In particular, it means that this:

 commit 171b9314bf2b2ed1719f2451b527960e0a363a40
 Author:     Stefan Kangas <stefan <at> marxist.se>
 AuthorDate: Tue Aug 9 14:29:12 2022 +0200
 Commit:     Stefan Kangas <stefan <at> marxist.se>
 CommitDate: Tue Aug 9 17:58:15 2022 +0200

     Replace utility functions with seq-uniq

     * lisp/gnus/gnus-util.el (gnus-delete-duplicates):
     * lisp/ibuf-ext.el (ibuffer-remove-duplicates): Redefine as
     obsolete function alias for 'seq-uniq'.  Update callers.

is incorrect: those callers should have been replaced with a faster
implementation than seq-uniq could ever become.

Previous Next

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