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: Thu, 17 Mar 2016 02:47:10 +0200 Message-ID: References: <20160312215839.GC10781@acm.fritz.box> <20160313175922.GE1871@acm.fritz.box> <0ce1b5a5-6892-47ad-03d4-d4c2ba2bea54@yandex.ru> <20160314122330.GC1894@acm.fritz.box> <20160314172940.GG1894@acm.fritz.box> <04defc46-af0c-6345-1570-83c1ae4ce14f@yandex.ru> <20160314184621.GH1894@acm.fritz.box> <20160314212024.GK1894@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 1458175653 7676 80.91.229.3 (17 Mar 2016 00:47:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 17 Mar 2016 00:47:33 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 17 01:47:28 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 1agM62-0000TJ-3Y for ged-emacs-devel@m.gmane.org; Thu, 17 Mar 2016 01:47:26 +0100 Original-Received: from localhost ([::1]:59516 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agM61-0005IJ-4i for ged-emacs-devel@m.gmane.org; Wed, 16 Mar 2016 20:47:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agM5x-0005I4-48 for emacs-devel@gnu.org; Wed, 16 Mar 2016 20:47:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agM5t-0004lH-1R for emacs-devel@gnu.org; Wed, 16 Mar 2016 20:47:21 -0400 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:34999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agM5s-0004kn-K6 for emacs-devel@gnu.org; Wed, 16 Mar 2016 20:47:16 -0400 Original-Received: by mail-wm0-x22d.google.com with SMTP id l68so208062025wml.0 for ; Wed, 16 Mar 2016 17:47:16 -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=1ej7znXIRuXtYAshGlb1CLU29KPX0yWEwTLih5Hfot4=; b=GWtO+z+caMzlQzYW5W3OfOei4sZia9jBZb35fnH17NXJHSp5brcMhKgXYUBwqGLTjh kbu88x4Vca732COKCrjC/UGa7Od+Flp9vm+8A28xxe+U7oz038HRK3tI66pr/RXy7m9r 1Jlt7thEuQvuzRJWFQsBeJyge8+R5hMfA5DapxvIMTEDV1OF3O+GdgMSIOdA0JH5+MlZ V8f/tf0LASIrpGDUFuu4ueokLgj/wMsHFxwOaKyHLN2ckSv2fmqaEkM5rd3feLaBDiiA vTQFhEJD5o6ONJTq/S9xD9CODF/PcYOCy4CfcNHxL3TWjG2mG7RZUrXPaHySw8j1hnAP pSGg== 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=1ej7znXIRuXtYAshGlb1CLU29KPX0yWEwTLih5Hfot4=; b=QATgW6K8jFxI797Krb2o4HH7FFSau9sINMSsd2L+io4sp/6nw2lko9s+9o7LsjogFi +6msHyZcIlGheWglyJF4/RWak1YByf4rlf7AHJZ4pUREYdJTF18k8ZRpmkwuojznhuIm Rgj0IB/tC9fXj4nhCqiONqBLhMOZiOOEftN0aWRXsN3Z16PBPV04TidDVsgWiDyL/Fi8 3mJM3K9ZDcX07Q3YLQt0N4OQzyERm/4br9udi9qILuy8k+IOLT04Fi11435EoK+VqCa2 Di7osaQPC6E2wCGFdfTlS4MICQhAJEd06nzQdwCOgyvfprijhFUcXns2m2dvxqHH+1Z+ 57uw== X-Gm-Message-State: AD7BkJLdRkmA3HUPRlgBkNxmFWUw5aIE91jvDC06Vsh/Fj6WZrh/NFu+Cbp/pTcpjlSHEA== X-Received: by 10.194.84.171 with SMTP id a11mr6439567wjz.91.1458175635767; Wed, 16 Mar 2016 17:47:15 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id up6sm5259571wjc.6.2016.03.16.17.47.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 17:47:12 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160314212024.GK1894@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::22d 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:201807 Archived-At: On 03/14/2016 11:20 PM, Alan Mackenzie wrote: > I meant, its deficiencies need fixing, and it's not clear at this stage > how that's to be done. I've said elsewhere what I expect to happen: > that it will be superseded by a different function with the same name. And I've replied to it already. The "deficiencies" aren't fixed yet because they haven't bothered anyone enough yet. The narrowing thing is relatively minor, compared e.g. to bug#23019 you've filed recently. Fixing that one would at least change the "internal data" of parse-partial-sexp. >> Apparently, the point is that you've been offered a simpler solution for >> the same problem, and that you basically ignored it. > > The simpler solution is a solution to a subset of the problem, more of a > workaround than a solution in my view, as I've already said. It does fix #22884 as described, though. I've checked. >> [...] you'd first have to let me know what to test. > > Working out what to test is the time consuming bit. The reproducible test case is a normal part of a patch submission, in the absence of a prior bug report. A patch looking for a problem would be silly. >> If the comment cache patch doesn't actually help with 22884, why are >> we even discussing it? > > Because it solves the problem which was the ultimate cause of bug > #22884. And yet it doesn't solve 22884? How odd. >> Ah, so the speed advantage of using text properties is not that much of >> advantage. Correct? > > It's currently unknown. That's one reason I'd like to get it merged > with master, so as people could try it out. As already discussed, on > certain restricted tests it's significantly faster. Why don't we just collect the actual cases where CC Mode is slow, and test improvements against those? Instead of pushing changes to master and using the early adopters as one big distributed testing facility. I mean, anticipating unknown problems sounds nice, but it's hardly the most important thing, given we have plenty of known ones. >> Can you produce a test case where it fails? This time without involving >> narrowing, please. > > Of course not. The code is twisted, with lots of special cases, > exceptions, and so on. It even notes in its comments certain corner > cases which won't work. It will fail again. High-level Lisp and abstractions are hard, let's write everything in assembly. Then it'll surely never fail. If the code is as unreliable as you say, producing a problem case should be trivial. > Anyhow, when you're testing something like this, what's the point of > only testing with nice easy cases? The code must work correctly with or > without narrowing. In other words, you can't give a single problem example which wouldn't involve narrowing? And which *would* work with text property-base cache. > It's slightly more impressive than a 60% decrease in performance. Note > that the test wasn't specially written to exhibit high performance (like > some "benchmark" tests are arranged to do). If someone provides an arbitrary piece Lisp code, and a patch which speeds up it execution by say 100%, the usefulness of the patch can still be questioned if the code is never a hot spot in practice.