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

[Gdobbins]

> is there some benchmark or test case that drives your desire to add that bytecode?

I don't have a specific benchmark in mind, but I did some tests with `benchmark-run` before I submitted the first patch to see how much faster it was. I remember the break even point between length= in C without a bytecode and just using = and length in byte-compiled code being somewhat high, on the order of 100. It is also necessarily slower when none of the arguments are lists. So it is difficult to know whether converting such cases to length= with a compiler macro is worth while since I don't know the average length of lists which are being compared this way, but I suspect it isn't. Compounding the issue would be the increase in size of the .elc files.

> but without dedicating a bytecode to it

I didn't actually add a bytecode. Instead I re-purposed the = bytecode to handle both cases, since (= list1 list2) isn't acceptable anyway. Because of this you actually get a bytecode for length= for free. Done this way length= always beats = and length separately. Plus, the .elc files actually get smaller since two bytecodes (= and length) are replaced with one (= alone).

The only real downside to overloading this bytecode is a loss of type-checking to =. To compensate and aid in debugging any issues caused by this I made the compiler surround all the arguments to = with nonsense additions of 0 to regain the type-checking when `byte-compile-delete-errors` was nil. Consequently I changed that variables default value to t, otherwise you've lost more than you've gained by doing this.

So I suppose the first real issue is whether or not that change to `byte-compile-delete-errors` is acceptable, or using some alternative option which defaults to allowing = to be byte-compiled with this loss of type-checking is acceptable.

-- Graham Dobbins