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 01:12:37 +0300 Message-ID: <29a94d23-c92e-ac66-2a19-64d7d1b86290@yandex.ru> References: <054393f3-3873-ab6e-b325-0eca354d8838@gmx.at> <20200403174757.GA8266@ACM> <20200405111623.GB5049@ACM> <20200406193633.GD7100@ACM> 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="109357"; 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, Stefan Monnier , eliz@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Apr 07 00:13:32 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 1jLZzk-000SF5-Id for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Apr 2020 00:13:28 +0200 Original-Received: from localhost ([::1]:38584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLZzj-0006Cx-KE for ged-emacs-devel@m.gmane-mx.org; Mon, 06 Apr 2020 18:13:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43050) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLZz1-0005mQ-AA for emacs-devel@gnu.org; Mon, 06 Apr 2020 18:12:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLZz0-00007I-1j for emacs-devel@gnu.org; Mon, 06 Apr 2020 18:12:43 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:41349) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLZyz-00005F-RD; Mon, 06 Apr 2020 18:12:41 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id h9so1421141wrc.8; Mon, 06 Apr 2020 15:12:41 -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=x/uxzV7AIlvXQaueDkqonIT2P1ZSl+5AV0cyAiA1k3c=; b=SlGRNAurXXQUXpyCjO/bJBXcu/NhZMxFzkQgR+0LjEzqRXC9S3z5VpiOq73+qQEbNS l/vnzfMl4/J1lzkzrjtaX3f6pjRQXh6axiQ5zfcj1tEeMt7jQzQLoHK8T7vSzKxk5lvy 5HYdl0gv4uU8viqCl0ps62DnEBrhyfn0KSV8wJ1Dyq0pmEfUVU7VvUap7SaGQpevFBBI jFNBYrKt2SkaUYHp1Z5gOj/ck31EvkpjwbEQc2tqOvGsQtHitKxG6ST2VxqxngFpd4o9 /XJ6z5z0Tzx4t/rLW/RXpcLr6QJUiSTpD1R37KZ1NCXGelNcv9IpZdA7ZU8rfEv1NVkd EwGA== 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=x/uxzV7AIlvXQaueDkqonIT2P1ZSl+5AV0cyAiA1k3c=; b=WdBp5NbyHTuDVq3e/8J6Os4eP8y6ScAxxBzugxUm4BFy6a5fVqKL4Mj29KlqodljMb M+tjV/lEVhLm3Yax2olEc1zK9AYPstvZynk9zTMMIzwPMMxHsHpn5Qo0uL7PUej/rYnf j6zjXgEgCpuAuMHwAwNN6rI3fwnQAh2ZGGeiu/48lGle9Qcv4k8jexnsluiZFEphCBFB HeA+IDnjONff5Z17ULZHKHUZ/7DTx7eQfXasMFrbS1yzkkaoTsm+AvhhNFH2GEM82NQp tXq50qiyBx/D5yFLIxiK/ZkTn6MZxHzxNNE236I8m2k8Sc19InsiQhMtXSJ4T9WgxZwv zr0w== X-Gm-Message-State: AGi0PuZ40QfAiw6ux8XBHbismgwm6z34vs9MN/zTR2EQcyzzhjvRGDGR h2IbEqoJ7cPNWiMwQB9eQUU= X-Google-Smtp-Source: APiQypKXyTYc1thT41anlYaQhCU6Y/Us+8DVdYVsOqkfTML/T8SPnUZCQ48B9f5tAwnBD7tGZoYSzA== X-Received: by 2002:adf:f808:: with SMTP id s8mr1548325wrp.219.1586211160186; Mon, 06 Apr 2020 15:12:40 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y22sm1561070wma.0.2020.04.06.15.12.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 Apr 2020 15:12:39 -0700 (PDT) In-Reply-To: <20200406193633.GD7100@ACM> 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::429 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:246570 Archived-At: Hi Alan, On 06.04.2020 22:36, Alan Mackenzie wrote: > I've attempted to simulate one of Martin's scenarios, and set up my tty > frame with two side by side windows, each 65 lines deep and wide enough > for xdisp.c not to need continuation lines. xdisp.c is displayed in both > windows, from Line 401 at the LHS, and from Line 35162 on the RHS. In > the LH window point is at BOL 435 (the opening brace for function > fill_column_indicator_column) and in the RH window point is at BOL 35159 > (a random line in start_hourglass). > > With various combinations of the pertinent variables, I run > > (time-it (insert "{") (other-window 1) (insert " ") (other-window 1) > (sit-for 0)) > > . After each such timing I undo the buffer changes before the next > timing. 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. How about some other, more common scenarios? Like Martin just scrolling the buffer (we can simulate that with several calls to scroll-up). Or Eli just typing in some large file. I think these two cases featured more prominently in the recent discussions, with associated complaints about performance. > 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. I can't imagine anybody doing the type-switch-window-to-the-same-buffer-type routine frequently, but if you really want to improve that use case, I think the first takeaway that the necessary knobs are still present. A text property check wouldn't slow the routines significantly (I think), but you'd have to benchmark that as well, and also the extra code in CC Mode which would scan the whole buffer and apply those properties. In the first implementation, at least, you could do that using the normal before/after-change-functions, not "super" ones. Here's a better idea to try, though: keep comment-use-syntax-ppss set to t. And also use syntax-ppss to find the beginning of defun in c-beginning-of-defun. But to make it honor the o-p-i-c-0-i-d-s, set syntax-begin-function to a new function that contains whatever "fast" logic you prefer. E.g. scanning the buffer back for open parens in column 1 without certain text property applied. I'm not 100% sure why this var is marked obsolete now (probably because it creates murky semantics), but this is the simplest way to add this behavior, I think. In any case, I'm afraid all this won't bring any dramatic improvement in the more usual scenarios which I mentioned above. And we'll be back to looking for other ways to improve performance.