From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Mysterious fontification/C++ context issue - Patch for beginning-of-defun-raw. Date: Fri, 15 Dec 2006 01:53:40 +0100 Message-ID: <858xha7ze3.fsf@lola.goethe.zz> References: <20061210014526.GB3738@muc.de> <877ix0lfm8.fsf@furball.mit.edu> <20061210102249.GA1235@muc.de> <87d56rpk7a.fsf@stupidchicken.com> <20061213224009.GA1206@muc.de> <87odq72ssy.fsf@stupidchicken.com> <20061214084713.GA1333@muc.de> <45812BDF.5050107@gmx.at> <20061214193733.GA1269@muc.de> <877iwuxljy.fsf@stupidchicken.com> <20061214232857.GA1239@muc.de> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1166144074 32399 80.91.229.10 (15 Dec 2006 00:54:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 15 Dec 2006 00:54:34 +0000 (UTC) Cc: martin rudalics , Chong Yidong , emacs-devel@gnu.org, Richard Stallman , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 15 01:54:30 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1Gv1LJ-0002rY-F5 for ged-emacs-devel@m.gmane.org; Fri, 15 Dec 2006 01:54:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gv1LJ-00077v-0z for ged-emacs-devel@m.gmane.org; Thu, 14 Dec 2006 19:54:29 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gv1L6-00077V-Rr for emacs-devel@gnu.org; Thu, 14 Dec 2006 19:54:16 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gv1L4-00075Z-NZ for emacs-devel@gnu.org; Thu, 14 Dec 2006 19:54:16 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gv1L4-00075Q-Gd for emacs-devel@gnu.org; Thu, 14 Dec 2006 19:54:14 -0500 Original-Received: from [212.7.152.120] (helo=mxout03.versatel.de) by monty-python.gnu.org with esmtp (Exim 4.52) id 1Gv1L3-0000Ek-AU; Thu, 14 Dec 2006 19:54:13 -0500 Original-Received: from mx05.versatel.de (mx01.versatel.de [212.7.146.1]) by mxout03.versatel.de (8.12.11/8.12.11) with ESMTP id kBF0ru1t027648; Fri, 15 Dec 2006 01:54:04 +0100 Original-Received: from lola.goethe.zz (i5387A029.versanet.de [83.135.160.41]) by mx05.versatel.de (8.12.11.20060308/8.12.11) with ESMTP id kBF0ru9W028812; Fri, 15 Dec 2006 01:53:56 +0100 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 76AC31C3DB40; Fri, 15 Dec 2006 01:53:40 +0100 (CET) Original-To: Alan Mackenzie In-Reply-To: <20061214232857.GA1239@muc.de> (Alan Mackenzie's message of "14 Dec 2006 23\:18\:22 +0100\, Thu\, 14 Dec 2006 23\:28\:57 +0000") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.91 (gnu/linux) 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:63751 Archived-At: Alan Mackenzie writes: > With the patch I suggested last night, you still find an initial M-> > in xdisp.c too slow (~4 seconds on your 1.7 GHz PC). That's a > massively large file. How fast must this operation be before you'd > find it acceptable? In emacs/src, there are files.c of all sizes, > ranging from pre-crt0.c (484 bytes) to xdisp.c (722032 bytes). If > David Kastrup's conjectured "quadratic dependency" were true (I > don't think it is), then a "typical" sized file.c (say, eval.c at > just over 100k) would take ~0.1 seconds for this. If the dependency > is linear, it would take ~0.5 seconds. > > Please satisfy my curiosity, experiment with decreasing file sizes, > and tell me at what file size the reaction becomes too slow for you. The problem appears not quadratic on file size to me, but rather quadratic on function size, or average fontification search size. So large automatically generated code passages would be candidates for performance hits. The large slowdown most likely would not be necessary if information was reused intelligently and not scanned repeatedly. That requires a good analysis and careful implementation/reimplementation. And the end of the pretest is the wrong time to start something like this. And it is also the wrong time to check in a half-baked solution that makes for somewhat more pleasing results while causing large performance hits. The feature is not ready for Emacs 22. And there is no useful plan that would make it become so. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum