Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.

[Alan Mackenzie]

Hello, Eli.

On Sun, Nov 25, 2018 at 20:15:30 +0200, Eli Zaretskii wrote:
> > Date: Sun, 25 Nov 2018 17:59:29 +0000
> > From: Alan Mackenzie <address@hidden>
> > Cc: address@hidden, address@hidden, address@hidden,
> >     address@hidden, address@hidden, address@hidden

> > > > The idea behind symbols-with-pos-enabled is that it will be a 32/64 bit
> > > > integer permanently in cache, hence can be tested for zero/non-zero
> > > > rapidly.

> > > This is premature optimization, we have gazillions of such tests in
> > > our inner loops (e.g., see bidi.c), one more or one less shouldn't
> > > matter.

> > It's a straightforward way of writing it, without using any contorted
> > code, so even if it is optimisation, it's harmless optimisation.

> The premature optimisation here is to worry about performance without
> timing the code.

> > But right from the beginning of the exercise, I've had speed at the back
> > of my mind.  If the slowdown had been 30%, the Emacs project leadership
> > would have been very unhappy about the idea.

> As I said, I'd be very surprised if using DEFVAR_BOOL would slow down
> what you did in any significant way, beyond the slowdown due to the
> comparison and struct member access.

I'll time it, then we'll know.

> > My current trouble arises from the need to access the variable both from
> > C and from Lisp.

> DEFVAR_BOOL defines a variable accessible both from C and Lisp.

> > I'm still a little confused as to what a DEFVAR_BOOL is.

> It's a C 'bool'.  Look at defvar_bool the function: its last argument
> is a pointer to the C counterpart of a DEFVAR_BOOL.

> You can also use ptype in the debugger to see what it really is, if
> you want to be absolutely sure.

OK, thanks for the explanation.  I'll change the declaration of that
variable (and another one) to DEFVAR_BOOL, and tidy up lisp.h to match.

Then I'll time the resulting Emacs again.  :-)

-- 
Alan Mackenzie (Nuremberg, Germany).