From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] comment-cache 223d16f 2/3: Apply `comment-depth' text properties when calling `back_comment'. Date: Mon, 14 Mar 2016 18:15:13 +0200 Message-ID: References: <20160308183010.GB6269@acm.fritz.box> <20160309174816.GE3948@acm.fritz.box> <56E0805F.3050804@gmx.at> <20160312170839.GE2572@acm.fritz.box> <20160312215839.GC10781@acm.fritz.box> <20160313175922.GE1871@acm.fritz.box> <0ce1b5a5-6892-47ad-03d4-d4c2ba2bea54@yandex.ru> <20160314122330.GC1894@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1457972170 17390 80.91.229.3 (14 Mar 2016 16:16:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Mar 2016 16:16:10 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 14 17:16:04 2016 Return-path: Envelope-to: ged-emacs-devel@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 1afVA3-0002F6-Sg for ged-emacs-devel@m.gmane.org; Mon, 14 Mar 2016 17:16:04 +0100 Original-Received: from localhost ([::1]:42131 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afVA2-0003Vr-AV for ged-emacs-devel@m.gmane.org; Mon, 14 Mar 2016 12:16:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afV9O-0003TI-1B for emacs-devel@gnu.org; Mon, 14 Mar 2016 12:15:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afV9K-0002Gp-FR for emacs-devel@gnu.org; Mon, 14 Mar 2016 12:15:21 -0400 Original-Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:35715) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afV9K-0002Gf-46 for emacs-devel@gnu.org; Mon, 14 Mar 2016 12:15:18 -0400 Original-Received: by mail-wm0-x234.google.com with SMTP id l68so115327993wml.0 for ; Mon, 14 Mar 2016 09:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0fgoP27Cn8Kn/xrhNTi5nw8LFZopvFD//W+flPCoVE0=; b=hQKd9JJfOEzQKwz6ikFQ+CiRVKV3iKQUD5WiRwxdZn7eaOBS5iUHpUGJKn9TF2CLwb MTc9ANR6x4oWdi6jE6XaJGUMxzx2SOy1pF5tA6q9Zi7cV1LmnphMVGsR0xwQHlgNbGXd 0lJt0dQI/pvLf8B6w0MxmcvTIklKF+03AMCw2ZsXhF39/ZHm3xW1lm+wCyaS5MONWqo5 CvIV1Oby+6tFl86gEqFFIF7XdZK8r9k8uaVRMtWQPOAqpEZMXZaPiF8s0zaC4ByyLo1Y OeSYftgPWoVz4tQhVj+rwgKVMQG/9LpS+8pvDRkrnRi5hSoPRSzEnHFx5FaLnLy3X7TN Rxgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0fgoP27Cn8Kn/xrhNTi5nw8LFZopvFD//W+flPCoVE0=; b=QeJZIZiHOAkawu7uDtGt2SyB5byhVhHA2UUAn/uzzTY5Zi5WlsLCWKKhKDmQyJPE8Y RLR/jjDChny4+SesUcLb4Mmn8KagZ11Gn4PcijTSxJoLvvt3Tux8EWa9ysoz6zsJEJFI 12Vm6Zsgt7d7ZJQsYhaqZh+SEmYVMtCN/tPUKOmxogqK4PE8ArC2Vwilo218m8ZcgQ2j 76dmwEzg18RKvL+7j7LazHSg3JNi8gyKtB2mUWz6+M2ehAPiIiePAiHVh5+ttpom/Dlz hzaAaCjsaFWjkbg7BteJDuXtrXyGfwmmSWfiPwHxKHx2+7syEQXPkVKujryTjEmNjHAC UsrQ== X-Gm-Message-State: AD7BkJJPrnL2TyKvgL1awB4msFZ0vESKK2lLaizvWAC+7stJeJjTd2OIKN+lpdn8pklZwg== X-Received: by 10.28.173.143 with SMTP id w137mr19772437wme.101.1457972117297; Mon, 14 Mar 2016 09:15:17 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id h7sm16748471wmf.9.2016.03.14.09.15.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 Mar 2016 09:15:16 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160314122330.GC1894@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::234 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:201707 Archived-At: Hi Alan, On 03/14/2016 02:23 PM, Alan Mackenzie wrote: >> Any performance numbers on using this approach in C/l mode? > > [ By "this approach" I'm taking it you mean scanning forward from safe > positions.] No, using syntax-ppss's cache. Including the syntax-ppss-last variable. > No. Except it uses a lot of parsing forward from safe positions anyway. IIRC, Stefan posted a patch, which was like 10 lines long. Could you please try it already, so we can move on to discussing the actual performance problems of syntax-ppss, instead of theoretical ones? > It's two slow to use as a replacement for back_comment, in the sense I > would like to do - in place of scanning a comment backward character by > character, I want to use a cache (calculated by forward scanning) to > determine the beginning of a comment. Having to scan forward lots of > characters (as opposed to a few) is out of the question for this > application. The approach X is out of the question, because my approach Y is usually N times faster! Why is it out of the question? Can I say "premature optimization"? >> So I have to wonder why the "get out of a comment" feature is used in >> C/l mode so much that it becomes a bottleneck, and you get significant >> improvement in performance by dropping the caching logic to C. That is, >> of course, not a nice thing to ask considering the overall complexity of >> CC Mode, but still. > >> I don't see anything comparable to 10 second waiting described in >> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22884, when doing a >> comparable operation in a 5000-line Ruby file. > > Here's a quick summary of how that happened: on L1661 of config.h, C > Mode had to scan back to the beginning of a statement. That involved > going back over ~1600 lines of comments and preprocessor constructs. I went back to the revision a589e9a and rebuilt Emacs. I see the problem described in 22884. However, the line 1661 already is a beginning of a statement. It contains: #define _DARWIN_USE_64_BIT_INODE 1 Are we talking about the same file? > When it got to the critical comment and tried to go back over it, > (forward-comment -1) said nil, because of that paren in column 0. That > paren in column 0, although in a comment, was deemed to be the start of > a defun. C Mode was then trying to parse "code" over a region with a > 1600 line gap in the middle. > Hence the 10 second delay in seeing the > character echoed. Paul has purged our code of parens in column 0. But > it would be nice not to have the restriction. (parse-partial-sexp 1 (point)) on line 1661 takes ~0.002s here. (parse-partial-sexp 1 (point-max)) takes just a little above that. How do these timings translate into whole seconds of waiting after pressing '/'? > My point was that it is so simple that it _could_ be written in C, and > that without any great difficulties. "It was so simple that I made it more complex"? I mentioned C as a drawback, and it is. > Parts of it can only be written in > C (the bits that ensure the cache is marked stale when certain > sytax-table text properties are set/cleared when > `inhibit-modification-hooks' is bound to non-nil). These would have to be carefully considered, but if they make sense, they would have to be ported to syntax-ppss too somehow.