From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: emacs rendering comparisson between emacs23 and emacs26.3 Date: Tue, 7 Apr 2020 17:17:09 +0300 Message-ID: <90adab93-b2c7-51cb-daaf-0714c8c031f2@yandex.ru> References: <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200405111623.GB5049@ACM> <20200406193633.GD7100@ACM> <29a94d23-c92e-ac66-2a19-64d7d1b86290@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="10819"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: rms@gnu.org, emacs-devel@gnu.org, rudalics@gmx.at, rrandresf@gmail.com, Alan Mackenzie , eliz@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 07 16:18:37 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jLp3k-0002i5-S4 for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 16:18:36 +0200 Original-Received: from localhost ([::1]:48012 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLp3j-000164-NY for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 10:18:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53330) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLp2T-0000Nw-Ai for emacs-devel@gnu.org; Tue, 07 Apr 2020 10:17:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLp2R-0008A6-GP for emacs-devel@gnu.org; Tue, 07 Apr 2020 10:17:17 -0400 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:51611) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLp2Q-000897-5b; Tue, 07 Apr 2020 10:17:14 -0400 Original-Received: by mail-wm1-x32c.google.com with SMTP id z7so1922768wmk.1; Tue, 07 Apr 2020 07:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=DgsuCEVFdCNUxJ1sWCK8iCPVl7YAsfr8ML4YyD1+pIs=; b=UKBIEjReG//XKlyEyOVlQexsLAiRLkJYuCjLq08hZpWxYPliFzqUg+/CFuY9vcD4LY AvjMbPF/gU3q5NZ9c3Lt1LT6LGQx7yu+38VOHDQeth9LHibUzeCUOeVRnVIik8VHL9WP GIBlz6tyOc5C9Ur2fMyI41W0uAf7Eil7mFbNoyI8Gn5wFqN5OYVGXgqvi/hxmlrYBJtm pOxpl/NeyH9VTSZdrrOMQtoGqjmid63rOfqJDptowxSVJTCHFkbw0MA2dClLpzFG+/Jp GFh9U/3eL7i6mlLA/OxezTBG235A4NaWi2Nz0AN90XU0zeT0mkSGaF1ml7a81ivIdRxR vxWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=DgsuCEVFdCNUxJ1sWCK8iCPVl7YAsfr8ML4YyD1+pIs=; b=rEKja3fCgWA0IuCdoBIlPQPrA6Rsi94jvKhYbsJ8uBmysTtryaOHf5CU0V6Tc/RZhW VYkpYTaTbGI7jgHbbeRsL7dd9cPAuZmCZ8Z5kirm1TQ8sJQ9R2pNaUIo1YKvSPIG33zZ vwDd6XcMWF5V0vGCCvPgmiSeRM/2gi4N51c71iFW/4cK+yBzPgRFWQZ8J7OtFDq12qyI HSa1pZp88teJSfg3a+2jtWjIrtuU+pNayW1H93sEhkRyT24CyJwyU0/nndW2RZnNhMUT 7DW5WC85Y6udBqffbDXXdD8U7OaPAIbKQGdOcQM+W+DgPl14KKfm6qZ0wR4StyDwxB4H 4Wsg== X-Gm-Message-State: AGi0Pubh6gP7H4ktDm6LGi7+6ojQ9tUkF8sKHWre1CD2QqMJs+OXEf8k OLxWRBTR6Sz/PkB97DliRUU= X-Google-Smtp-Source: APiQypIJ0DJ1zcNup/YgeE4wzQvokGmrN89v3hiInm+bBVnxhid5DsWyejj1NF57rlos54Ilp9xBzA== X-Received: by 2002:a1c:9c85:: with SMTP id f127mr2732315wme.91.1586269032823; Tue, 07 Apr 2020 07:17:12 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 25sm2455179wmf.13.2020.04.07.07.17.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Apr 2020 07:17:11 -0700 (PDT) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::32c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246602 Archived-At: On 07.04.2020 02:41, Stefan Monnier wrote: >> So you chose the absolute worst scenario for syntax-ppss, right? Where its >> cache would be unavoidably clobbered at least once. I'm guessing the >> difference between measurements is ~ how long (parse-partial-sexp >> (point-min) (point-max)) takes on your machine in that file. > > FWIW, `syntax-ppss` has not been optimized for this case at all, so > I wouldn't be surprised if it takes noticeably more than > > (parse-partial-sexp (point-min) (point-max)) > > because it performs that computation in chunks, and the overhead for > each chunk is likely non-negligible. The times it takes here, in an optimized build, fluctuates from 0.02 to 0.05. So indeed, the difference is larger. But the same order of magnitude, which is still pretty good, IMO. >>> Here are the results: >>> open-paren-in-column-zero-is-defun-start >>> nil t >>> comment-use-syntax-ppss >>> nil 0.319s 0.264s >>> t 0.319s 0.227s >>> . Bearing in mind that c-u-s-p being t suppresses the action of >>> o-p-i-c-0-i-d-s in back_comment, but not in beginning-of-defun, it seems >>> like the o-p-i-c-0-i-d-s mechanism does indeed speed up some scenarios >>> in C Mode, significantly but not massively. >>> IMAO, It would be nice to have the code testing o-p-i-c-0-i-d-s (both >>> places) able to ignore spurious cases of parens in literals. > > The problem here is that in order to decide whether or not it's *still* > spurious after the change near BOB, you basically have to compute the > equivalent of `syntax-ppss`. So we're back to square one. That's a good point. In this particular scenario all column-1 parens down in the buffer should be invalidated. > What could be done is to change `syntax-ppss` so it optimizes for the > case where the buffer changes do not impact the way parsing is done > "further down" (i.e. not for the case where the change just opened (or > closed) a string/comment). Not sure it's worth the trouble, OTOH. Yup. Not sure either, but let's see what feedback others give. Or we could try indefinitely supporting the "worse-is-better" semantics offered by o-p-i-c-0-i-d-s if, again, it's really in demand.