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:23:10 +0200
> 
> Eli Zaretskii <eliz@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.