bug#49127: closed (Performance degradation in encode_coding_object)

[GNU bug Tracking System]

Your message dated Tue, 17 Aug 2021 15:35:08 +0300
with message-id <835yw46ygz.fsf@gnu.org>
and subject line Re: bug#49127: Performance degradation in encode_coding_object
has caused the debbugs.gnu.org bug report #49127,
regarding Performance degradation in encode_coding_object
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
49127: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=49127
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Performance degradation in encode_coding_object
>
>
>
>
> Date: 
>
> Sun, 20 Jun 2021 08:30:24 +0200
>
>
>
>
> Hi,
>
> All of the following applies to Emacs 27.1 and 28.0.50.
>
> Im currently debugging a performance degradation in haskell-mode. When editing 
> code in a terminal frame, over time as I make modifications to source code, 
> redrawing lines during scrolling becomes continuously slower to the point that 
> it sometimes takes up 200ms for a single line to draw. This problem disappears 
> once the GC runs.
>
> With gprof/prof_events I have nailed the problem to be encode_coding_object 
> looping over all markers. In degenerate cases this list can contain millions of 
> markers. Traversing this list is particularly slow because of the indirection 
> being a singly linked list. Based on the fact that a GC remedies this, I’m 
> assuming this list contains mostly  unreachable markers. When stepping through 
> encode_coding_object with GDB after a GC this list of markers shrinks to small 
> double digit numbers from millions.
>
> The source of these markers appears to be looking-at in the font locking code 
> of haskell-mode, this assumption is based on the fact that commenting out the 
> uses of looking-at in haskell-mode prevents the accumulation of markers and 
> thus the slowdown.
>
> One contributing factor to all of this, is that for lsp-mode to perform 
> adequately, one needs a relatively high gc-cons-threshold, which means GCs that 
> would clean up the markers run more rarely, leading to higher accumulation of 
> markers over time.
>
> This problem only triggers in terminal frames, but not in GUI frames. Setting 
> GDB breakpoints suggests that the GUI frame never even calls into 
> encode_coding_object.
>
> So far I’m torn on whether this is a bug in the haskell-mode font locking code 
> or in Emacs. What do you think?
>
> Kind regards,
> Victor
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#49127: Performance degradation in encode_coding_object
>
>
>
>
> Date: 
>
> Tue, 17 Aug 2021 15:35:08 +0300
>
>
>
>
> > Date: Sun, 15 Aug 2021 18:07:23 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: 49127@debbugs.gnu.org
> > 
> > Ping! Ping! Ping! Please respond!
>
> This should now be fixed on the master branch.
>
>
> --- End Message ---