unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Ravine Var <ravine.var@gmail.com>
Cc: "Mattias Engdegård" <mattiase@acm.org>,
	"Lars Ingebrigtsen" <larsi@gnus.org>,
	25706@debbugs.gnu.org
Subject: bug#25706: 26.0.50; Slow C file fontification
Date: Wed, 9 Dec 2020 18:46:55 +0000	[thread overview]
Message-ID: <X9Ebn7hKnG/vpDcZ__39217.4103691772$1607544034$gmane$org@ACM> (raw)
In-Reply-To: <878sa7h1a2.fsf@gmail.com>

Hello, Ravine.

Thanks for doing all this testing!

On Wed, Dec 09, 2020 at 13:01:31 +0530, Ravine Var wrote:
> Alan Mackenzie <acm@muc.de> writes:
> > Anyhow, please try out the (?)final version of my patch before I commit
> > it and close the bug.  It should apply cleanly to the master branch.  I
> > might well split it into three changes, two small, one large, since
> > there are, in a sense three distinct fixes there.

> I tested this patch, along with Mattias' patch posted earlier, on two
> machines.

> On a reasonably fast machine (AMD Ryzen 3 3200G with 16 GB RAM), there
> is a marked improvement in visiting and scrolling the header files
> in the linux kernel tree. The complete lockups that happened earlier
> did not happen.

That is close to the spec of my machine, and I find that these large .h
files (without braces), with the patch, now work fast enough for me.

> I also tested the patches on a Chromebook (Intel Celeron N2840 with 4GB
> RAM), which is similar to the machine in the original report.
> Unfortunately, the behavior was still bad, with lockups and freezing.
> I tried both c-mode and c++-mode with font-lock-maximum-decoration set
> to 2.

Thank you indeed for taking the trouble to test the patch on the lesser
machine.  I do not have access to such a machine.  I am assuming that
before this patch, such a large file like osprey_reg....h would have
been completely unworkable on the machine.  It sounds as though it still
is.  However, have you noticed any improvement at all in performance?

Could I ask you please to do one more thing, and that is to take a
profile on this machine where it is giving trouble.  From a freshly
loaded buffer, move forward (if necessary) to a troublesome spot.  N.B.
C-u 1 M-> moves to 10% away from the end of the buffer, C-u 2 M-> 20%,
and so on.  Then start the profiler and do what is causing sluggish
performance.  Then have a look at the final profiler output, and expand
it sensibly so that the troublesome function can be found.

(Optional paragraph.)  How to use the profiler: Do M-x profiler-start
RET, and accept the default mode with another RET.  Perform the stuff to
be profiled.  Do M-x profiler-report, which gives three or four lines of
output, each with a number and a percentage.  Move point to a line with
a large percentage and type RET to expand it.  You can repeat this to
expand further.  Please expand the lines down to where the percentages
remaining are around 5% or 6%.  There will be quite a lot of lines near
the start showing the same large percentage.

Then could you please post that output here, so as to give me some idea
of where the poor performance is coming from.  Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).





  parent reply	other threads:[~2020-12-09 18:46 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-13 18:20 bug#25706: 26.0.50; Slow C file fontification Sujith
2020-11-30 11:26 ` Lars Ingebrigtsen
2020-11-30 11:37   ` Lars Ingebrigtsen
2020-11-30 12:46 ` Mattias Engdegård
2020-11-30 12:49   ` Lars Ingebrigtsen
2020-11-30 16:27   ` Eli Zaretskii
2020-11-30 16:38   ` Alan Mackenzie
2020-11-30 16:53     ` Mattias Engdegård
2020-11-30 17:04       ` Mattias Engdegård
2020-12-01  5:48         ` Ravine Var
2020-12-01 13:34           ` Mattias Engdegård
2020-12-01  9:29         ` Alan Mackenzie
2020-12-01  9:44           ` martin rudalics
2020-12-01 10:07             ` Alan Mackenzie
2020-12-01  9:21       ` Alan Mackenzie
2020-12-01 12:03         ` Mattias Engdegård
2020-12-01 12:57           ` Alan Mackenzie
2020-12-01 14:07             ` Mattias Engdegård
2020-12-01 15:27               ` Alan Mackenzie
2020-12-01 18:59                 ` Mattias Engdegård
2020-12-02 10:15                   ` Alan Mackenzie
     [not found]                   ` <X8dpQeGaDD1w3kXX@ACM>
2020-12-02 15:06                     ` Mattias Engdegård
2020-12-03 10:48                       ` Alan Mackenzie
2020-12-03 14:03                         ` Mattias Engdegård
2020-12-04 21:04                           ` Alan Mackenzie
     [not found]                           ` <X8qkcokfZGbaK5A2@ACM>
2020-12-05 15:20                             ` Mattias Engdegård
2020-12-08 18:42                               ` Alan Mackenzie
     [not found]                               ` <X8/JG7eD7SfkEimH@ACM>
2020-12-08 19:32                                 ` Mattias Engdegård
2020-12-09  7:31                                 ` Ravine Var
2020-12-09  7:47                                   ` Ravine Var
2020-12-10  8:08                                     ` Alan Mackenzie
2020-12-09 18:46                                   ` Alan Mackenzie [this message]
     [not found]                                   ` <X9Ebn7hKnG/vpDcZ@ACM>
2020-12-09 20:04                                     ` Eli Zaretskii
2020-12-09 20:32                                       ` Alan Mackenzie
2020-12-10 17:02                                     ` Ravine Var
2020-12-10 20:02                                       ` Alan Mackenzie
2020-12-11 10:55                                         ` Ravine Var
2020-12-12 15:34                                           ` Alan Mackenzie
     [not found]                                           ` <X9TjCeydJaE2mpK8@ACM>
2020-12-14  7:20                                             ` Ravine Var
2020-12-14 11:44                                               ` Alan Mackenzie
2020-12-15  4:01                                                 ` Ravine Var
2020-12-15 12:27                                                   ` Alan Mackenzie
2020-12-09 17:00                                 ` Mattias Engdegård
2020-12-10 12:26                                   ` Alan Mackenzie
2020-11-30 18:30   ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='X9Ebn7hKnG/vpDcZ__39217.4103691772$1607544034$gmane$org@ACM' \
    --to=acm@muc.de \
    --cc=25706@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=mattiase@acm.org \
    --cc=ravine.var@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).