bug#11822: 24.1; emacsclient terminal mode captures escape characters as text

[Eli Zaretskii]

> Date: Wed, 23 Sep 2015 13:27:26 -0400
> From: Ken Raeburn <raeburn@permabit.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 11822@debbugs.gnu.org
> 
> So far my testing is going smoothly. (Well, except for some unrelated issues
> like the desktop save file format changing and making it hard to go back to 
> the
> older version.) And as far as I can tell, creating a new frame on the local
> display at work is not doing anything that stops to wait for communication 
> with
> the remote display. It's much faster now.
> 
> It's still not what I would call "fast", though, usually taking a couple of
> seconds... but a cursory investigation is so far pointing the finger at 
> garbage
> collection being triggered during frame creation, more often than not. If I
> raise gc-cons-threshold by a factor of 10, frame creation and display is 
> fairly
> quick (presumably only 90-95% of the time).

Let me know when you are satisfied with your testing, so I could merge
the branch onto master.

> The C stack traces from the garbage collection calls are pretty
> boring (maybe_gc gets called from Ffuncall which gets called from
> exec_byte_code etc); the Lisp backtraces point the finger mostly at
> internal-face-x-get-resource as the function being entered when GC
> gets invoked.

The function that triggers GC is not necessarily the main culprit for
GC.  In http://lists.gnu.org/archive/html/emacs-devel/2015-08/msg00081.html
I described how I went about tracking the worst offenders, so I suggest
you do something similar.  Once you have the data based on a watchpoint
put on consing_since_gc, you can analyze it to see which code is
responsible for most of the consing.  With that data in hand, we could
see if there's something we can do about that.

> A memory profile report of frame creation via emacsclient includes this
> breakdown:

The so-called "memory profile" is not profiling memory, at least not
in the useful sense applicable to the issue at hand.  In its current
implementation, it doesn't present useful data for debugging
Lisp-level data memory allocations.