Re: [Emacs-diffs] master e828765: DEFVAR_INT variables are now intmax_t

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 27 Feb 2019 17:50:10 -0800
> 
> On 2/27/19 8:13 AM, Eli Zaretskii wrote:
> > Doesn't this slow down 32-bit builds?  We have quite a few of
> > DEFVAR_INTs in Emacs.
> 
> Emacs has 55 DEFVAR_INTs. This patch affects their width only on 32-bit
> builds sans --with-wide-int. On my platform (Fedora 29 AMD Phenom II X4
> 910e compiled with gcc -m32 -march=native), narrowing DEFVAR_INTs back
> from 64 to 32 bits (see attached patch) shrinks Emacs's bss space (as
> computed by 'size') from 379144 to 378984 bytes, a savings of 0.04%. I
> tried to measure how much it affects CPU performance but couldn't get
> consistent results; it seems to be below the level of significance,
> though if I tried harder I might be able to tease it out.

Depends on what code you ran to test that, I presume.

Looking at the list of DEFVAR_INTs, I see that about 40% of them are
in the display engine, where speed certainly matters, although perhaps
not in "emacs -Q".  the ones in keyboard.c are also of some
importance.

So on balance, I guess I wonder why this minor aesthetic or maybe
convenience issue is worth slowing down Emacs on those hosts.  We have
lived with this limitation for a long time, so why not leave it alone?
Just because we _can_ make them bignums doesn't necessarily mean we
should.