GNU bug report logs - #42490
Emacs is very slow when navigating into a specific C++ file

Previous Next

Package: emacs;

Reported by: Olivier Scalbert <olivier.scalbert <at> algosyn.com>

Date: Thu, 23 Jul 2020 11:00:02 UTC

Severity: normal

Fixed in version 27.1

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 42490 <at> debbugs.gnu.org (full text, mbox):

From: Olivier Scalbert <olivier.scalbert <at> algosyn.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Mattias EngdegÄrd <mattiase <at> acm.org>,
 42490 <at> debbugs.gnu.org
Subject: Re: bug#42490: Emacs is very slow when navigating into a specific C++
 file
Date: Mon, 21 Sep 2020 19:29:28 +0200
Hello Alan,

Ping reply !
;-)

I was sure I had already answered. Sorry for that. With a fresh compile 
of Emacs 27.1, it is effectively faster than before. So, for me, you can 
close the bug. Many thanks ! Regards, Olivier



On 9/21/20 11:06 AM, Alan Mackenzie wrote:
> Hello, Olivier.
>
> Ping?
>
> On Fri, Jul 24, 2020 at 21:34:51 +0200, Olivier Scalbert wrote:
>> Hi,
>> Thanks for your answer.
>> Unfortunately, I am out of my home, with no PC, for the week-end.
>> If I'll survive, I will test it next Monday. Very sorry !
>> ;-)
> Emacs 27.1 was released just a few weeks ago.  Maybe you're already
> using it.
>
> I think CC Mode processes the test file fast enough on 27.1, so it's
> probably time to close this bug.  What do you say?
>
>> Regards,
>> Olivier
>
>
>
>
>
>
>> On 7/24/20 9:24 PM, Alan Mackenzie wrote:
>>> Hello, Mattias and Olivier.
>>> Firstly Olivier, thanks for taking the trouble to report the bug.
>>> On Fri, Jul 24, 2020 at 18:46:45 +0200, Mattias EngdegÄrd wrote:
>>>> Hello Olivier,
>>>> Thanks for the report! Could you try Emacs 27 (or git master), building
>>>> from source if necessary? Those versions should be slightly faster,
>>>> although the response time is probably well below acceptable.
>>>> If we distill the essentials of your file to some sort of benchmark, we
>>>> might end up with:
>>>> (with-temp-buffer
>>>>     (c++-mode)
>>>>     (dotimes (_ 1000)
>>>>       (insert "OP(ed,b0) { ldir(); } /* LDIR */\n"))
>>>>     (garbage-collect)
>>>>     (let ((t0 (current-time)))
>>>>       (font-lock-ensure (point-min) (point-max))
>>>>       (time-to-seconds (time-since t0))))
>>>> Emacs 26.3 runs it in 11.9 s on this old lappy, but Emacs 27 does it in
>>>> 3.3 s. This is a clear improvement but we should be able to do better.
>>>> Alan may have a feeling for where the cycles are spent.
>>> I've bisected CC Mode to find the critical change, and it is:
>>> commit cc80eeb4a43d2079963de3d181002a6a6b56560d
>>> Author: Alan Mackenzie <acm <at> muc.de>
>>> Date:   Fri Apr 12 20:07:03 2019 +0000
>>>       Analyze C++ method with & or && ref-qualifier as defun, not brace list
>>>       Also firm up detection of beginning of brace list in
>>>       c-looking-at-or-maybe-in-bracelist.
>>> I have a simple benchmark which scrolls through a file, fontifying it,
>>> and my results from this benchmark are:
>>> (i) Before applying that patch: 53.022s.
>>> (ii) After applying that patch:  7.039s.
>>> I don't understand at the moment why that patch sped up scrolling in your
>>> (Olivier's) file, but it would seem the patch is most desirable.
>>> Unfortunately, the patch won't apply cleanly to the Emacs 26.3 sources.
>>> It might be possible to find a sequence of patches which would do the
>>> job.  I think (though I haven't checked) the patch will have been
>>> included in the upcoming Emacs 27.1 release.





This bug report was last modified 4 years and 295 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.