bug#70686: 30.0.50; cl--position is slow

bug#70686: 30.0.50; cl--position is slow

[No Wayman]

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.

bug#70686: 30.0.50; cl--position is slow

[Eli Zaretskii]

> From: No Wayman <iarchivedmywholelife@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?

bug#70686: 30.0.50; cl--position is slow

[No Wayman]

Eli Zaretskii <eliz@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.

bug#70686: 30.0.50; cl--position is slow

[Eli Zaretskii]

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

bug#70686: 30.0.50; cl--position is slow

[No Wayman]

Eli Zaretskii <eliz@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.