all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 25.3 => 26.1, C-mode, slow again
@ 2018-08-04 21:36 Winston
  2018-08-06  1:28 ` Stefan Monnier
       [not found] ` <mailman.4722.1533518950.1292.help-gnu-emacs@gnu.org>
  0 siblings, 2 replies; 5+ messages in thread
From: Winston @ 2018-08-04 21:36 UTC (permalink / raw)
  To: help-gnu-emacs

Summary: I'm looking for the (possibly renamed in Emacs 26) variable
         that controls how much effort to go to (incl. how far to look
         back) in C-mode to determine the syntax of what's visible
         on-screen.

Details:
I recently upgraded from Emacs 25.3 (where everything was working well)
to 26.1, and an old problem of slowness has come back again.

The case where it's most apparent is in c-mode, in an initialized static
array containing tens of thousands entries, with several values per
entry / line, some values numeric and some string.  Simple incremental
searches that were nearly instantaneous in 25.3 now take 4-8 seconds.
Simple edits (kill line, yank line, kill word, type new word in a
string, undo) that also were instantaneous in 25.3 now sometimes take
10-40 seconds.

This problem first appeared several years ago with an earlier Emacs
upgrade (23 => 24?).  I don't recall the name of the variable I had to
change to fix it back then, and nothing in my .emacs file catches my eye
as being it.  Maybe font-lock-maximum-decoration? (but I'm thinking
not).

What I do recall is that the variable had 3 states:

#1: (probably t) (the default) Do however much work is needed to
   determine the correct C syntax for the code on-screen, and the
   correct indentation for the indent line function;

#2: (probably nil) disable the feature;

and #3: (might have been any value other than t or nil) Limit the effort
   spent to determine the syntax and indentation, and just look at other
   code in the vicinity.

Back then, the default setting was very slow, just like what I'm seeing
now.  I remember doing something to switch to mode 3: the slowness
vanished, and it did the right thing ~99% of the time [once in a while
in a long C function, c-indent-line would get the indentation wrong].

Anyone know what the variable's (possibly changed) name is, or otherwise
how to fix the slowness?  The difference between an Emacs that takes 3-4
seconds not only to echo each change but also even just to scroll
forward or backward a screenful, versus an Emacs that responds
instantly, is huge (to me).

Thanks in advance,
 -WBE


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 25.3 => 26.1, C-mode, slow again
  2018-08-04 21:36 25.3 => 26.1, C-mode, slow again Winston
@ 2018-08-06  1:28 ` Stefan Monnier
       [not found] ` <mailman.4722.1533518950.1292.help-gnu-emacs@gnu.org>
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2018-08-06  1:28 UTC (permalink / raw)
  To: help-gnu-emacs

> This problem first appeared several years ago with an earlier Emacs
> upgrade (23 => 24?).

The problem you describe is a bit like a traffic jam.
So even tho you may have seen another problem in an earlier Emacs which
also looked like a traffic jam, the similarity likely ends there: the
actual origin of the problem can be extremely diverse.


        Stefan




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 25.3 => 26.1, C-mode, slow again
       [not found] ` <mailman.4722.1533518950.1292.help-gnu-emacs@gnu.org>
@ 2018-08-06 19:31   ` Winston
  2018-08-07  4:22     ` Stefan Monnier
  2018-08-07 13:47     ` Filipp Gunbin
  0 siblings, 2 replies; 5+ messages in thread
From: Winston @ 2018-08-06 19:31 UTC (permalink / raw)
  To: help-gnu-emacs

I originally wrote:
>> This problem first appeared several years ago with an earlier Emacs
>> upgrade (23 => 24?).

to which Stefan Monnier <monnier@iro.umontreal.ca> kindly replied:
> The problem you describe is a bit like a traffic jam.
> So even tho you may have seen another problem in an earlier Emacs which
> also looked like a traffic jam, the similarity likely ends there: the
> actual origin of the problem can be extremely diverse.

You may be right.

As part of getting 26.1 to work, I found several (setq default-var)s
that had to be changed to (setq-default var), and it's not uncommon for
function names and variable names to change as major version numbers
increase.  I thought maybe whichever variable I set to fix the problem
last time had had its name changed.

I was actually more surprised that I couldn't identify what I did the
time before.  The main reason I described the variable was in hopes
someone would recognize the description and tell me what *that* variable
was, even if it isn't the cause of my current problem.

As to the current issue, it's not just in C-mode, though it's more
apparent there.  I'm also seeing a very tiny but perceptible lag even in
a small, plain text buffer (such as while composing this reply) when
doing just (forward-line) and (backward-line) that only moves the cursor
and does no scrolling.  That lag wasn't there in 25.3.

Thanks for the reply,
 -WBE


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 25.3 => 26.1, C-mode, slow again
  2018-08-06 19:31   ` Winston
@ 2018-08-07  4:22     ` Stefan Monnier
  2018-08-07 13:47     ` Filipp Gunbin
  1 sibling, 0 replies; 5+ messages in thread
From: Stefan Monnier @ 2018-08-07  4:22 UTC (permalink / raw)
  To: help-gnu-emacs

> As to the current issue, it's not just in C-mode, though it's more
> apparent there.  I'm also seeing a very tiny but perceptible lag even in
> a small, plain text buffer (such as while composing this reply) when
> doing just (forward-line) and (backward-line) that only moves the cursor
> and does no scrolling.  That lag wasn't there in 25.3.

If you can reproduce it at will, I recommend you M-x report-emacs-bug to
try and help Emacs maintainers find the origin of your problem.


        Stefan




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: 25.3 => 26.1, C-mode, slow again
  2018-08-06 19:31   ` Winston
  2018-08-07  4:22     ` Stefan Monnier
@ 2018-08-07 13:47     ` Filipp Gunbin
  1 sibling, 0 replies; 5+ messages in thread
From: Filipp Gunbin @ 2018-08-07 13:47 UTC (permalink / raw)
  To: help-gnu-emacs

> As to the current issue, it's not just in C-mode, though it's more
> apparent there.  I'm also seeing a very tiny but perceptible lag even in
> a small, plain text buffer (such as while composing this reply) when
> doing just (forward-line) and (backward-line) that only moves the cursor
> and does no scrolling.  That lag wasn't there in 25.3.

What platform are you on?  I think I'm seeing similar tiny lags on macOS
--with-threads (and not seeing --without-threads).  But I'm not yet
confident enough to report that.



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2018-08-07 13:47 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-04 21:36 25.3 => 26.1, C-mode, slow again Winston
2018-08-06  1:28 ` Stefan Monnier
     [not found] ` <mailman.4722.1533518950.1292.help-gnu-emacs@gnu.org>
2018-08-06 19:31   ` Winston
2018-08-07  4:22     ` Stefan Monnier
2018-08-07 13:47     ` Filipp Gunbin

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.