From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Wed, 23 Sep 2015 22:17:29 +0300 Message-ID: <83k2rhj67q.fsf@gnu.org> References: <6eipe9fypj.fsf@just-testing.permabit.com> <415962DC-9BF5-4595-8180-7BE8DB545206@permabit.com> <502427D2.3080003@permabit.com> <83ipcre0fm.fsf@gnu.org> <2AB38709-2307-437E-A242-70B8A358BE4F@permabit.com> <83a9y3dwa8.fsf@gnu.org> <838vdndv9m.fsf@gnu.org> <1341183F-84AB-4257-B28B-57BDE5CA4F20@permabit.com> <83r3m97bzs.fsf@gnu.org> <37C523EE-3D76-40F7-B7B2-99D6F0BD7B97@permabit.com> <83bndc7r5b.fsf@gnu.org> <6ea8swr8ja.fsf@just-testing.permabit.com> <83si6n65ld.fsf@gnu.org> <6e613irc91.fsf@just-testing.permabit.com> <83bnda5lso.fsf@gnu.org> <6ezj0tphtd.fsf@just-testing.permabit.com> <83h9n14e04.fsf@gnu.org> <6esi6kpn4t.fsf@just-testing.permabit.com> <834miv92nm.fsf@gnu.org> <83a8sjreso.fsf@gnu.org> <838u80nm2e.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1443035911 20198 80.91.229.3 (23 Sep 2015 19:18:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2015 19:18:31 +0000 (UTC) Cc: monnier@iro.umontreal.ca, 11822@debbugs.gnu.org To: Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 23 21:18:18 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZepYQ-0000If-5m for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Sep 2015 21:18:10 +0200 Original-Received: from localhost ([::1]:50162 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepYP-00069Y-IC for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Sep 2015 15:18:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepYM-00068y-9T for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 15:18:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZepYJ-0005iA-2W for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 15:18:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZepYI-0005i4-VF for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 15:18:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZepYI-0005xm-Gg for bug-gnu-emacs@gnu.org; Wed, 23 Sep 2015 15:18:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Sep 2015 19:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11822 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11822-submit@debbugs.gnu.org id=B11822.144303585522888 (code B ref 11822); Wed, 23 Sep 2015 19:18:02 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 23 Sep 2015 19:17:35 +0000 Original-Received: from localhost ([127.0.0.1]:43022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZepXq-0005x5-GV for submit@debbugs.gnu.org; Wed, 23 Sep 2015 15:17:34 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:60099) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZepXm-0005wv-T7 for 11822@debbugs.gnu.org; Wed, 23 Sep 2015 15:17:32 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NV500C008YRML00@mtaout27.012.net.il> for 11822@debbugs.gnu.org; Wed, 23 Sep 2015 22:13:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NV500BVD9F2KK20@mtaout27.012.net.il>; Wed, 23 Sep 2015 22:13:50 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106847 Archived-At: > Date: Wed, 23 Sep 2015 13:27:26 -0400 > From: Ken Raeburn > Cc: Stefan Monnier , 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.