bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#25706: 26.0.50; Slow C file fontification


From: Alan Mackenzie
Subject: bug#25706: 26.0.50; Slow C file fontification
Date: Wed, 9 Dec 2020 18:46:55 +0000

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





reply via email to

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