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

[Ken Raeburn]

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

I printed out stack traces when consing_since_gc changed. That turns out to be 
a lot of raw data :-) … it took 5.5 CPU hours under gdb to get the frame 
created and the data recorded. It’s over 120MB of text, so I’m working on 
distilling it down to something that might be useful. Some highlights so far:

In this run, I recorded over 601000 bytes being allocated; about 60% of that 
(~364000) was done from things called by parse_single_submenu; about half of 
that (~185000), in turn, was via larger_vector called from ensure_menu_items. 
The largest of those was a single allocation of 62000 bytes. There were several 
more of these calls, with smaller sizes, and varying in the nesting depth of 
single_menu_item and friends.

The next couple paths resulting in the most bytes allocated were list creations 
from Lisp code:

39104 bytes across 2444 allocations with the Lisp backtrace: set-face-attribute 
apply face-spec-reset-face face-spec-recalc face-set-after-frame-default 
x-create-frame-with-faces PVEC_COMPILED@0x121eac8 apply frame-creation-function 
make-frame make-frame-command funcall-interactively call-interactively 
command-execute

36288 bytes across 2268 allocations with the Lisp backtrace: append apply 
face-spec-reset-face [… as above]

58320 bytes across 3645 allocations via mapcar or the function mapcar applies, 
called from face-spec-reset-face

There were also 54360 bytes allocated along various paths from directory-files, 
which as far as I can tell is only used to test for the existence of any file 
in ~/.emacs.d/auto-save-list with a name starting with “.saves-”. If any exist, 
the “Recover Crashed Session” menu item is enabled. But I know of no way to do 
just the pattern matching and existence test without fetching all the other 
data. The amount of wasted allocations are dependent on the content of my 
directory, of course.

This stuff described above is all during the execution of “make-frame-command” 
invoked via C-x 5 2. After that command completes, there are more allocations 
driven out of redisplay_internal or timers — enough that garbage collection ran 
a second time — but I’m not sure which are normal parts of the 
create-and-display-frame sequence (loading image files) and which may be 
artifacts of how I did the test or how I was using the machine (e.g., random X 
events caused by my moving other windows around to get real work done over the 
span of a few hours).

Ken