|
From: | Paul Eggert |
Subject: | Crashes in "C-h h" |
Date: | Wed, 3 Jul 2019 14:05:32 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 |
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.001swhich 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.
t.c
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |