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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70686 in the body.
You can then email your comments to 70686 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

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 #8 received at 70686 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: 70686 <at> debbugs.gnu.org
Subject: Re: bug#70686: 30.0.50; cl--position is slow
Date: Wed, 01 May 2024 14:59:47 +0300

> From: No Wayman <iarchivedmywholelife <at> gmail.com>
> 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.

Not sure why is this a bug report.  If cl-position is too slow for
your application, you can always use something else, something that is
less generic and more tailored to your specific sequence type(s), no?

Message #11 received at 70686 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70686 <at> debbugs.gnu.org
Subject: Re: bug#70686: 30.0.50; cl--position is slow
Date: Wed, 01 May 2024 08:20:56 -0400

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

> Not sure why is this a bug report. 

Slow performance, especially in a widely used library like cl-lib, 
is a bug.
Where would you prefer such observations be reported?

> If cl-position is too slow for your application, you can always 
> use
> something else, something that is less generic and more tailored 
> to your specific sequence type(s), no?

As stated, I've done that and am aware of the general 
performance/flexibility trade-offs.
It would be preferable to improve the performance of that 
function, as it would benefit anyone using it.

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.

Message #14 received at 70686 <at> debbugs.gnu.org (full text, mbox):

From: No Wayman <iarchivedmywholelife <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70686 <at> debbugs.gnu.org
Subject: Re: bug#70686: 30.0.50; cl--position is slow
Date: Wed, 01 May 2024 08:23:56 -0400

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

> Not sure why is this a bug report.  If cl-position is too slow 
> for

Not `cl-position'. `cl--position', which is at the bedrock of 
other functions. 
e.g. cl-remove, cl-delete, cl-delete-duplicates, cl-remove-duplicates, etc.

Message #17 received at 70686 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: No Wayman <iarchivedmywholelife <at> gmail.com>
Cc: 70686 <at> debbugs.gnu.org
Subject: Re: bug#70686: 30.0.50; cl--position is slow
Date: Wed, 01 May 2024 15:34:19 +0300

> 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.

Message #22 received at 70686-done <at> debbugs.gnu.org (full text, mbox):

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.