GNU bug report logs - #70686
30.0.50; cl--position is slow

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#70686: closed (30.0.50; cl--position is slow)
Date: Sat, 01 Mar 2025 02:38:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Fri, 28 Feb 2025 18:37:39 -0800
with message-id <CADwFkmn_vuwpV+vuiB_09EeAfmG-=f-8CQFToKDdEbkQQ16rzg <at> mail.gmail.com>
and subject line Re: bug#70686: 30.0.50; cl--position is slow
has caused the debbugs.gnu.org bug report #70686,
regarding 30.0.50; cl--position is slow
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
70686: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70686
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; cl--position is slow
Date: Tue, 30 Apr 2024 19:51:23 -0400

I've recently been avoiding cl-position, cl-remove-duplicates, and any other functions which use it internally. I realize there's a performance trade-off in for the flexibility such functions provide, but it may be worth investigating cl--position in particular. Today I replaced an instance of cl-remove-duplicates with an equivalent cl-loop for a 15x performance improvement at the cost of 2 lines of code.

[Message part 3 (message/rfc822, inline)]

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70686-done <at> debbugs.gnu.org, No Wayman <iarchivedmywholelife <at> gmail.com>
Subject: Re: bug#70686: 30.0.50; cl--position is slow
Date: Fri, 28 Feb 2025 18:37:39 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: No Wayman <iarchivedmywholelife <at> gmail.com>
>> Cc: 70686 <at> debbugs.gnu.org
>> Date: Wed, 01 May 2024 08:20:56 -0400
>>
>> It would be preferable to improve the performance of that
>> function, as it would benefit anyone using it.
>
> Sure, if you have a patch to improve performance, please share it.
>
> But otherwise asking for better performance here is not very useful,
> because we'd like to improve performance of everything in Emacs.  IOW,
> the need and the motivation exist, but without some practical
> suggestion how to improve there's no way to resolve such issues raised
> here.
>
> So:
>
>> Slow performance, especially in a widely used library like cl-lib,
>> is a bug.
>> Where would you prefer such observations be reported?
>
> I think only cases of abysmally inadequate and terribly slow
> performance should be reported as bugs, when there's no practical
> suggestion for improving the performance.
>
>> Are you confident the performance trade-off is due to dispatching
>> on sequence types in this case?
>> Do you think the performance could be improved without sacrificing
>> that flexibility?
>> I'll dig into it more when I have time, but I'm starting a
>> discussion here in case someone has already made an attempt or
>> knows the answers to those questions.
>
> Discussions generally don't belong here.  A better place for that is
> emacs-devel, if only because many more people read it.
>
> Thanks.

I'd tend to agree.  It's hard to do anything actionable with this bug
report.  Work on improving the performance of cl--position and
everything else is of course more than welcome.

I'm therefore closing this bug report.

Previous Next

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