Re: emacs-26 eec71eb: Speed up replace-buffer-contents

[Paul Eggert]

> > > Which particular problem were did you allude to?
> >
> > Sorry, I've lost context and don't know what this question refers to.
>
> It refers to this exchange:
>
> > > I typically measure effectiveness of performance tweaks when using the
> > > 'configure' default of CFLAGS='-g3 -O2', since that's how it's typically built
> > > downstream. If this particular problem is all about CFLAGS=-O0 please let me
> > > know, as I guess I can look at that too (but would rather not).
>
> > Which particular problem were did you allude to?
>
> You said "if this particular problem is about ...", and I asked what
> was the particular problem you were talking about.

Ah, I meant the particular performance problem that the recent changes have been 
trying to alleviate.

> It's not rarely_quit that is expensive, it's the few calls to
> maybe_quit it does, because maybe_quit accesses two Lisp symbols.  I
> think.

If that's the case, there's still a performance bug in there. The point of 
rarely_quit is to avoid calling maybe_quit in the vast majority of cases. If 
maybe_quit is being called so often that it's a performance hog, then it's being 
called too often.

By the way, accessing Lisp symbols should not be a serious performance 
bottleneck. builtin_lisp_symbol takes zero machine instructions unless compiling 
with -fcheck-pointer-bounds or compiling without optimization. If 
builtin_lisp_symbol is a serious performance issue when compiling without 
optimization (which it shouldn't be), then we need to tune its uses for the 
non-optimized case (though I'd rather avoid that sort of thing, as it is a 
throwback to the 1970s to be hand-optimizing to work around lousy compilers!). 
But before resorting to this, I'd first rather understand the maybe_quit problem 
mentioned above.