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

[Ken Raeburn <raeburn@permabit.com>]

[-- Attachment #1: Type: text/plain, Size: 3624 bytes --]

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

Lisp Backtrace:
"internal-face-x-get-resource" (0x1910fb80)
"set-face-attribute-from-resource" (0x1910fd80)
"set-face-attributes-from-resources" (0x1910ff80)
"make-face-x-resource-internal" (0x19110170)
"face-spec-recalc" (0x19110360)
"face-set-after-frame-default" (0x19110560)
"x-create-frame-with-faces" (0x19110758)
0x121eac8 PVEC_COMPILED
"apply" (0x19110a10)
"frame-creation-function" (0x19110c10)
"make-frame" (0x19110dc0)
"make-frame-on-display" (0x19110f88)
"server-create-window-system-frame" (0x191111b8)
"server-process-filter" (0x19111398)

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

- server-process-filter                                     2,898,676   2%
 - server-create-window-system-frame                        1,526,354   1%
  - make-frame-on-display                                   1,522,279   1%
   - make-frame                                             1,522,279   1%
    - frame-creation-function                               1,509,219   1%
     - apply                                                1,509,219   1%
      - #<compiled 0x487ab3>                                1,509,219   1%
       - x-create-frame-with-faces                          1,509,219   1%
        - face-set-after-frame-default                        372,148   0%
         - face-spec-recalc                                   371,868   0%
          - make-face-x-resource-internal                     368,460   0%
             set-face-attributes-from-resources               368,460   0%
          + face-spec-choose                                    2,384   0%
          + face-spec-set-2                                     1,024   0%
      normal-erase-is-backspace-setup-frame                    13,036   0%
    + run-hook-with-args                                           24   0%
    window-system-for-display                                   1,024   0%
 - server-execute-continuation                              1,355,452   1%
  - #<compiled 0x175dd37>                                   1,355,452   1%
   - server-execute                                         1,349,604   1%
      switch-to-buffer                                      1,269,569   1%
    + server-delete-client                                     36,910   0%

However, I'm skeptical of the numbers since the report also indicated that
read-from-minibuffer (but not things it called) used 100M (bytes? cells?)
in those few seconds. (Hence the >2MB shown here being such a tiny
percentage.) And the numbers vary a lot from one attempt to another, though
the proportions seem to be fairly consistent.

Ken

[-- Attachment #2: Type: text/html, Size: 4770 bytes --]