emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: emacs-26 eec71eb: Speed up replace-buffer-contents
Date: Wed, 04 Jul 2018 21:40:22 +0300

> Cc: address@hidden, address@hidden
> From: Paul Eggert <address@hidden>
> Date: Wed, 4 Jul 2018 11:30:12 -0700
> 
> 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.

Maybe I'm mistaken, then.  I will see what an optimized build shows.

> If builtin_lisp_symbol is a serious performance issue when compiling
> without optimization (which it shouldn't be)

It is a serious bottleneck in an unoptimized build, if you call
builtin_lisp_symbol half a dozen times for each pair of characters
'compareseq' wants to examine -- which is what the original code did,
due to all the assertions it had there, some of them really paranoid
(like asserting that A + X is more than A after asserting that X is
positive).  I think the original code spent almost 50% of its time
inside builtin_lisp_symbol.

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

I don't think we need to optimize builtin_lisp_symbol, since the
situation in replace-buffer-contents is quite a unique one.

> But before resorting to this, I'd first rather understand the maybe_quit 
> problem 
> mentioned above.

The maybe_quit problem is/was due to its accessing 2 Lisp symbols,
which again involves calling builtin_lisp_symbol, and originally I
added a call to maybe_quit to buffer_chars_equal, so it would be
called for each pair of characters 'compareseq' wanted to examine.
That's why I switched to rarely_quit.



reply via email to

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