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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 25 Nov 2018 17:59:29 +0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: cpitclaudel@gmail.com, charles@aurox.ch, michael_heerdegen@web.de,
> 	emacs-devel@gnu.org, schwab@linux-m68k.org, monnier@IRO.UMontreal.CA
> 
> > > 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.

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