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

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

bug#49127: Performance degradation in encode_coding_object


From: Eli Zaretskii
Subject: bug#49127: Performance degradation in encode_coding_object
Date: Sun, 20 Jun 2021 12:04:59 +0300

> Date: Sun, 20 Jun 2021 08:30:24 +0200
> From:  Victor Nawothnig via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 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.

Do you understand why using looking-at causes creation of markers?  If
so, can you show the details of why this happens?

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

Yes, playing with GC threshold is usually a bad idea, but it is hard
to explain to people why, and they keep doing that, to their cost.

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

Can you should a backtrace from the call to encode_coding_object,
including the Lisp backtrace (via the "xbacktrace" command)?

> 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?

Let's revisit this question after we have all the data I requested
above, okay?

Thanks.





reply via email to

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