Re: Add a function for building sort predicates

[Daniel Mendler]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Daniel Mendler <mail@daniel-mendler.de> writes:
>
>> Did you perform some measurements, comparing with the hand-written
>> predicate in package.el?  The code does not look efficient with the
>> function calls and the throws.
>
> My version was around 6% slower. Using dynamic lookup of the key order.
> I did not try with native compiling.

Would be interesting to see the results with native compilation. I will
try it when I find time.

>> In contrast, if the macro creates a sequence of conditions the native
>> compiler can optimize the result. It all depends on the use case. If
>> the rules are supposed to be customizable and the lists are short, the
>> dynamic approach will likely work well enough. For long lists an
>> efficient sort predicate makes a difference in my experience, e.g., in
>> a dynamically updating completion UI with thousands of candidates,
>> since the predicate is called very often.
>
> A disadvantage is that custom option will have to introduce new :set
> dependencies, I wanted to avoid that.

What do you mean by :set dependencies? If we use a macro, customization
is not possible anymore. So if customization of the rules is a
requirement, then we have to go with a function. Another optimization
option is to transparently compile to byte code. Iirc such an approach
was discussed for `buffer-match-p'.

> But in some cases the speed difference might be worth such an
> optimization.  If you want to experiment, please be my guest.

Yes. The question is where this predicate builder is supposed to be
used. Probably interfaces like list-packages or generally tabulated-list
buffers would not profit so much from optimization. With ELPA and MELPA
the packages buffer has around 6000 entries.

Daniel