[Top][All Lists]

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

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

From: Paul Eggert
Subject: Re: emacs-26 eec71eb: Speed up replace-buffer-contents
Date: Wed, 4 Jul 2018 11:30:12 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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

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.

reply via email to

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