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

Previous Next

Full log

Message #40 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:59:03 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: stefan <at> marxist.se,  57079 <at> debbugs.gnu.org
> Date: Tue, 09 Aug 2022 19:52:51 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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.
> 
> I didn't make seq-uniq faster just when TESTFN is nil -- I made it
> faster for all lists, so I don't follow you at all here.

My point is that it will never be as fast as the implementations
Stefan deleted, replacing them with seq-uniq.  My point is that those
changes just made several places in Emacs slower, even after your
speedup, for no good reason.  Those deleted functions, if they needed
to be deleted, should have been replaced by a different
implementation, which doesn't support TESTFN and is therefore faster,
as the original implementations, now deleted, were.

Previous Next

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