[Top][All Lists]

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

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

From: Eli Zaretskii
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Sun, 25 Nov 2018 20:15:30 +0200

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

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

reply via email to

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