byte-optimize-nth and byte-optimize-nthcdr

In XEmacs 21.2 (beta19) "Shinjuku" [Lucid] (i586-pc-linux, Mule) of Sat Jul 31 1999 on libretto configured using `configure --extra-verbose --with-x11=yes --dynamic --with-png=yes --with-xpm --with-xface --with-database=berkdb --with-sound=native --with-mule --with-xim=no --with-xfs --site-libraries=/usr/local/lib' XEmacs has `nth' and `nthcdr' as C primitive; (subrp (symbol-function 'nth)) --> t (subrp (symbol-function 'nthcdr)) --> t byte-optimize.el changes `nth' and `nthcdr' to `car' and `cdr' combinations in source level optimizations. But are they really optimizations? Why two or more C primitives are faster than one? I will send a diff to xemacs-patches which will not change `nth' and `nthcdr' anymore. Thanks. -- Mikio Nakajima <minakaji(a)osaka.email.ne.jp&gt; <minakaji(a)pdx.ne.jp&gt; (in case of emergency) http://www.asahi-net.or.jp/~gy2m-nkjm/