GNU bug report logs -
#42490
Emacs is very slow when navigating into a specific C++ file
Previous Next
Full log
View this message in rfc822 format
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.