[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
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.