From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: Serious performance problem with process output on Mac OSX Date: Mon, 29 Mar 2010 19:54:54 -0400 Message-ID: <87iq8ey981.fsf@stupidchicken.com> References: <83634jglab.fsf@gnu.org> <831vf7ge57.fsf@gnu.org> <83y6hfeyzw.fsf@gnu.org> <83vdcig87f.fsf@gnu.org> <87k4sywpvv.fsf@stupidchicken.com> <83tys2fbxs.fsf@gnu.org> <87hbo1iubm.fsf@home.jasonrumney.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269906922 4630 80.91.229.12 (29 Mar 2010 23:55:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 29 Mar 2010 23:55:22 +0000 (UTC) Cc: Christian Lynbech , Emacs-Devel devel To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 30 01:55:10 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NwOnV-0006Un-Ak for ged-emacs-devel@m.gmane.org; Tue, 30 Mar 2010 01:55:09 +0200 Original-Received: from localhost ([127.0.0.1]:50491 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwOnU-00056p-Gh for ged-emacs-devel@m.gmane.org; Mon, 29 Mar 2010 19:55:08 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NwOnN-00056K-Oj for emacs-devel@gnu.org; Mon, 29 Mar 2010 19:55:01 -0400 Original-Received: from [140.186.70.92] (port=57565 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NwOnM-00055C-7E for emacs-devel@gnu.org; Mon, 29 Mar 2010 19:55:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NwOnK-0004WK-Hg for emacs-devel@gnu.org; Mon, 29 Mar 2010 19:55:00 -0400 Original-Received: from pantheon-po35.its.yale.edu ([130.132.50.83]:43351) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NwOnK-0004W2-En for emacs-devel@gnu.org; Mon, 29 Mar 2010 19:54:58 -0400 Original-Received: from furry (dhcp128036014175.central.yale.edu [128.36.14.175]) (authenticated bits=0) by pantheon-po35.its.yale.edu (8.12.11.20060308/8.12.11) with ESMTP id o2TNssvU026057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Mar 2010 19:54:54 -0400 Original-Received: by furry (Postfix, from userid 1000) id 994D0C05D; Mon, 29 Mar 2010 19:54:54 -0400 (EDT) In-Reply-To: (Adrian Robert's message of "Tue, 30 Mar 2010 00:58:33 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.94 (gnu/linux) X-YaleITSMailFilter: Version 1.2c (attachment(s) not renamed) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122891 Archived-At: Adrian Robert writes: >> I suspect unneeded calls to one of the icon/icon_type methods in >> nsfns.m or the miniwindowimage methods in nsterm.m are causing this. >> Someone could try shortcircuiting these in the source and seeing if >> the problem still obtains. > > I went ahead and tried this. The culprit was an unneeded > ns_set_icon_type() call. The attached patch cleans this up by > removing some HAVE_NS special handling in xdisp.c. Thank you very much. I've checked your patch into the emacs-23 branch. Can you verify that this also fixes the performance problem reported in [http://debbugs.gnu.org/cgi/bugreport.cgi?bug=2056]? I assume it's the same problem. One other thing I noticed which looking through the code is that the Nextstep port assigns a special value, `t', to frame-title-format, and processes it specially. Is there any reason to do this? If not, I think this should be removed; this looks like a misfeature to me, since it is not compatible with the variable as documented and can confuse other people's Lisp code.