Re: [PATCH] Add new lisp function length= with bytecode support

[Gdobbins <gdobbins@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]

> Why not `length-cmp' which will -1 if less, 0 if equal, 1 if greater?

Traversing lists on the lisp side with cdr is much slower than the nthcdr approach. I'm also not sure what using a helper function gains, the macro I wrote in the last patch defines all of them directly.

This is beginning to feel like bike-shedding. Would one of the maintainers like to make a decision about how to implement this? I've already spent far more time than I wanted implementing this minor bit of functionality 3 different ways, I'd like it if one could be picked and then if necessary minor corrections to it can then be made. As I see it there are 4 ways of going about this:

1. Implement length= and related in C. With the accompanying modifications to the byte-interpreter and compiler, this would be the most efficient in terms of faster execution and smaller bytecode.

2.. Implement everything in lisp. This wouldn't be nearly as efficient since the changes to the byte-interpreter can't be made, but would be an improvement for cases like (length= number list). Cases like (length= list1 list2) will suffer the most from a lisp definition. I don't think a compiler macro for = and related would be a good idea in this case since it would increase the size of .elc files and would be slower if none of the arguments are lists.

3. Implement the two argument forms (like length_eqlsign2 in the patch before last) in C and change the bytecode interpreter to use them, but implement the &rest forms in lisp like in the last patch. This would give most of the benefits of the first option while also having a lisp definition of the functions but letting byte-compiled code be transformed into the faster C version. The major drawback of this approach would be having two different implementations of the same functionality in different places, potentially making the code harder to maintain and debug. But with appropriate comments in place at both locations and proper tests for both I think this can be made negligible.

4. As in option 3 but length_eqlsign2 could be promoted to a full-fledged lisp function (with the prefix internal--) and the &rest form could be defined in lisp in terms of it. This would mitigate the major drawback of option 3 at the cost of exposing a C defined function into lisp, even if it is only for internal use. As in option 3 this option would be less efficient than option 1 only for forms with more than two arguments like (length< list1 list2 list3).

To summarize:
Option 1 will result in the overall fastest execution time.
Option 3 will result in most of that improvement and satisfy the condition of not defining any new lisp functions in C.
Option 4 has the same amount of improvement as 3 but defines an internally used lisp function in C to possibly mitigate bugs.
Option 2 is the slowest by far with the only benefit being no changes at all to the C sources.

Option 3 would seem to best accommodate everyone's desires. I'm happy to implement it, but only after I get confirmation that it will be acceptable.


-- Graham Dobbins

[-- Attachment #2: Type: text/html, Size: 3577 bytes --]