>> As Eli's revised code suggests, if n is in fixnum range, then instead of
>> (FIXNUMP (x) && XFIXNUM (x) == n) it's typically a bit cleaner (and faster) to
>> write EQ (x, make_fixnum (n)).

> It normally shouldn't matter either way, but in that case the
> comparison is done in a loop, so the make_fixnum call can be done just
> once, outside the loop, which AFAIU makes the loop a tad faster.

Although it indeed doesn't matter normally, the EQ+make_fixnum version 
should be smaller and faster in typical use, even without hoisting the 
make_fixnum out of a loop. I just now ran the attached microbenchmark on 
a Xeon E5-2640 v2 with code compiled by GCC 9.1 x86-64, and got these 
results:

1031-lnxsrv09 $ time ./a.out 0 0   # no operation

real	0m28.150s
user	0m28.148s
sys	0m0.001s
1032-lnxsrv09 $ time ./a.out 0 0 0   # FIXNUMP+XFIXNUM

real	0m34.229s
user	0m34.227s
sys	0m0.001s
1033-lnxsrv09 $ time ./a.out 0 0 0 0    # EQ+make_fixnum

real	0m32.213s
user	0m32.211s
sys	0m0.001s

which indicates that the EQ+make_fixnum version was about 50% faster 
than the FIXNUMP+XFIXNUM version, once you subtract the overhead of the 
no-op benchmark control.