[Q] Transform safe calls to (= X Y Z) to (and (= X Y) (= Y Z)); same for < > <= >=

[Aidan Kehoe]

 Ar an seachtú lá déag de mí Méan Fómhair, scríobh Stephen J. Turnbull: 

 > QUERY
 > 
 > Aidan Kehoe writes:
 > 
 >  > 	* cl-macs.el (= < > <= >=): When these functions are handed
 >  > more than two arguments, and those arguments have no side effects,
 >  > transform to a series of two argument calls, avoiding funcall in
 >  > the byte-compiled code.
 > 
 > Shouldn't this be limited to some number of arguments?  At some point
 > the byte interpreter overhead (vs the C implementation of these
 > functions) is going to outweigh funcall overhead. 

The byte interpreter overhead is three extra byte codes per iteration.
Here’s the funcall version of (<= a b 200):

byte code:
  args: nil
0	constant  <=
1	varref	  a
2	varref	  b
3	constant  200
7	call	  3
9	return	  

And the byte-code-op version:

byte code:
  args: nil
0	varref	  a
1	varref	  b
2	leq	  
3	goto-if-nil-else-pop 1
5	varref	  b
6	constant  200
7	leq	  
8:1	return	  

Hundreds of arguments and I’d worry about the extra octets, but there are no
literal calls to these functions with hundreds of arguments (as opposed to
calls constructed with #'apply.) Remember also that the C implementations of
the comparison functions have to loop, too.

 > Or is there another reason to avoid funcall besides overhead?

One other reason I avoid it is because funcall shows up in profiling
information and byte codes don’t, so there’s less noise when I’m trying to
work out why some operation is taking much longer than it should.

-- 
“Apart from the nine-banded armadillo, man is the only natural host of
Mycobacterium leprae, although it can be grown in the footpads of mice.”
  -- Kumar & Clark, Clinical Medicine, summarising improbable leprosy research