From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Bug #25608 and the comment-cache branch Date: Mon, 6 Feb 2017 19:37:56 +0000 Message-ID: <20170206193756.GC3568@acm> References: <20170202202418.GA2505@acm> <9d0b3156-e8b2-c2d8-0d0c-a025861e5e0c@yandex.ru> <20170203164457.GB2250@acm> <20170204110259.GB2047@acm> <883690aa-5749-1c6b-bcd7-7404dd0d9bf0@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1486409948 13380 195.159.176.226 (6 Feb 2017 19:39:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Feb 2017 19:39:08 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 06 20:39:04 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cap7v-0003DB-5y for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 20:39:03 +0100 Original-Received: from localhost ([::1]:50414 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cap7z-00064I-4m for ged-emacs-devel@m.gmane.org; Mon, 06 Feb 2017 14:39:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48950) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cap7G-00063G-0d for emacs-devel@gnu.org; Mon, 06 Feb 2017 14:38:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cap7B-0002LU-F3 for emacs-devel@gnu.org; Mon, 06 Feb 2017 14:38:22 -0500 Original-Received: from ocolin.muc.de ([193.149.48.4]:13021 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cap7B-0002L4-4G for emacs-devel@gnu.org; Mon, 06 Feb 2017 14:38:17 -0500 Original-Received: (qmail 5107 invoked by uid 3782); 6 Feb 2017 19:38:16 -0000 Original-Received: from acm.muc.de (p548C7532.dip0.t-ipconnect.de [84.140.117.50]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 06 Feb 2017 20:38:15 +0100 Original-Received: (qmail 3906 invoked by uid 1000); 6 Feb 2017 19:37:56 -0000 Content-Disposition: inline In-Reply-To: <883690aa-5749-1c6b-bcd7-7404dd0d9bf0@yandex.ru> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:212060 Archived-At: Hello, Dmitry. On Mon, Feb 06, 2017 at 03:28:44 +0200, Dmitry Gutov wrote: > Hi Alan, > On 04.02.2017 13:02, Alan Mackenzie wrote: [ .... ] > For any casual observers in this discussion who don't want to follow the > links: the patch touches src/syntax.c, and it's 20 lines long. > > syntax-ppss being too slow was its use in a specific circumstance. That > > was trying to use it in place of comment-cache's cache mechanism, but > > otherwise using comment-cache. That would result in ~2 orders of > > magnitude slowdown in backward_comment. > Ah, so that's what you were arguing against? Yes. I thought at the time that that's what you were advocating. > Does comment-cache code contain some other functionality that we'd want > to retain while using the syntax-ppss cache? Something that makes > performance overhead of syntax-ppss a problem still? There's the failure to clear the syntax-ppss cache (e.g. after applying syntax table properties) that I outlined in detail in my other post. comment-cache's cache is cleared correctly in these circumstances. > >>> The "alternative patch" didn't scan comments correctly all the time > >>> when I looked at it, just as the current back_comment doesn't. > >> Please remind us of the specific problems it has. > > In the following test case (same as in my other post) the "alternative > > patch" doesn't work. Narrow the buffer with point-min at the indicated > > position. Put point at EOL. Try M-: (forward-comment -1). This fails. > > char foo[] = "asdf asdf" "asdf"; /* "asdf" */ /* */ /* '"'" */ > > ^ > > . > Thank you for the reminder. But do you have any examples that do not > involve narrowing? No (other than cache clearing problems). The bug on a narrowed buffer is serious enough not to require "support" from other bugs. > Reconciling syntax-ppss with narrowing is a subject of a separate thread > (one that's regrettably stalled for a while, but I'll get back to it > soon). As soon as it's resolved, the Alternative Patch should not have > this problem anymore either. Not this one, no. > > Using M;- (time-scroll) from the start of xdisp.c, and (time-scroll t) > > from its end (having cleared caches by typing a character at BOB), I get > > these timings > > forward backward > > master 34.51s 36.43s > > comment-cache 33.68s 32.81s > > "alternative patch" 35.49s 36.05s > Thanks! > > It would seem that differences in speed are not big enough to make any > > decision on that basis. > Does that just leave the narrowing issues, or is there something else? See above and my other post from this evening for the "something else". -- Alan Mackenzie (Nuremberg, Germany).