Re: What's missing in ELisp that makes people want to use cl-lib?

[Dmitry Gutov <dmitry@gutov.dev>]

On 13/11/2023 01:14, João Távora wrote:
> On Sun, Nov 12, 2023 at 10:09 PM Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
>> So it seems on par with the hand-written version (byte-compiled, too)
>> that hardcodes the test function.
>>
>> Curiously, though, if I make list2 longer (e.g. 12 elements rather than
>> 6), then my/set-difference starts to win noticeably (0.166 vs 0.200).
> 
> I have a suspicion, I'll see what I can do.
> 
> More importantly, there's an important takeaway here.  Your
> results seem to show that regardless of the alternative (cl-lib
> or hand-rolled) the solution with Emacs's current recommended
> sequence processing library is nearly 6 times slower in a
> real-world use-case.

Note that it's still the difference for the case where the "business 
logic" (the filtering predicate or whatever) doesn't do anything. 
Although certain order-of-magnitude differences are worrying.

> Maybe seq.el can be made faster too?  Who knows, but it seems
> difficult without breaking at least some of its defgeneric-based
> contract.

I was wondering whether you tried looking into seq.el's performance 
problems. It being slower on shorter lists is quite expected: if the 
type dispatch has non-negligible overhead, that should be most 
noticeable when the rest of the work is small.

The case with longer lists and other data structures should be possible 
to improve, though. As long as the type dispatch only happens once per 
sequence, and not for each element.

>> I'll keep the real-world case as-is (code in project--vc-list-files)
>> both because the result with cl-nset-difference is still a little
>> slower, and because it's slower in all released emacsen, but it
>> definitely becomes an option.
> 
> Not that I think it's worth it just for this, but isn't cl-lib.el a
> :core package?

It's not: the version in ELPA is a small backward-compatibility shim for 
older emacsen.