bug#57079: 29.0.50; Performance of seq-uniq is not very good

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: stefan@marxist.se,  57079@debbugs.gnu.org
> Date: Tue, 09 Aug 2022 19:52:51 +0200
> 
> Eli Zaretskii <eliz@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.