[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: Re: [Emacs-diffs] master e828765: DEFVAR_INT variables are now intmax_t
Date: Thu, 28 Feb 2019 20:09:36 +0200

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> 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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]