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: Fri, 10 Apr 2020 06:33:13 +0300 Message-ID: References: <83sghhss8v.fsf@gnu.org> <671b5b41-663d-5ab9-f022-dc6c5ce54dd0@yandex.ru> <83r1x1sqkx.fsf@gnu.org> <83lfn9s63n.fsf@gnu.org> <83h7xvqsgc.fsf@gnu.org> <90749329-ccb1-f96e-29c0-b4ecbb81d1d4@yandex.ru> <20200407174217.GC4009@ACM> <50acd968-4459-2fab-1609-7869e1ed072a@yandex.ru> <20200408020913.GA3992@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="40098"; 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: rudalics@gmx.at, Eli Zaretskii , rrandresf@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 10 05:34:04 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 1jMkQe-000AJA-7B for ged-emacs-devel@m.gmane-mx.org; Fri, 10 Apr 2020 05:34:04 +0200 Original-Received: from localhost ([::1]:58118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMkQd-0006Gs-6K for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Apr 2020 23:34:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46856) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jMkPv-0005pI-Sk for emacs-devel@gnu.org; Thu, 09 Apr 2020 23:33:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jMkPu-0004Qy-Jl for emacs-devel@gnu.org; Thu, 09 Apr 2020 23:33:19 -0400 Original-Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:38760) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jMkPu-0004QZ-B8; Thu, 09 Apr 2020 23:33:18 -0400 Original-Received: by mail-wm1-x32e.google.com with SMTP id f20so1346728wmh.3; Thu, 09 Apr 2020 20:33:18 -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=AjLMF+aj8eFaCqF1OwRAsoj1QyBnCeq0FDamqP3Yrbg=; b=phWVjND7CWNywLZBzEQ0YeuqKiN/N5QOaQElguq+evgiGGuNFII9Y37N6eeggsAub6 B5GxLqh54nL7pwEwbmXOB5/YfH0SKmMCiO+1CutUKWRG/m3JUnLCrVHjKumXBdYAg9QR dtOA6wxdBKUcx9x6DnD44fcwYtprQ+3DSESIlzasChSHyBqXX+w0j9MsknhGH7VRYW3P FlsoUt9mQE6bLVJiC9lX5HFRUcqnJkkXkIdKKxIrMsYlwx1cOWrt96CFghyaGNCa9SMS W1j5+ADQBdCW5Ggv6mocQA00dqN6bNh2kyiICA/qc1/nUDXiUUtockYfbOvFJWtCaCdP LGfQ== 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=AjLMF+aj8eFaCqF1OwRAsoj1QyBnCeq0FDamqP3Yrbg=; b=CldI8fPsZhAvz13K75YKiqlYn6uZyUqZxaP5JdNHeYB0I2KCU12FOv0ndeh1CCj+qr fvzzIP55pXOWcWXwOunFI3jJWHGHqlmSZbynfQ/5oQPoOkUW7zBaB+xAV8xzZE3aJ71K SQumvH5O0mC0DQ+UEZ9U8UGIh8bui+zI04RFIs+xWMC8FtMY3KxCFLCoZ7Ae3KkxMKo7 8gwvn9aYeUr59Mxk65c6hrZfL4fwwcXnQ8N47F47C65EAde5OisI8lGzi1ElHXUMlhxK yDPKZ3SxTBBjZtR0N4i+DVEPDe8yiBiC8Tm2vqMXgCad3uD/zKDnm6jWAxENCpBxx2vU BzMg== X-Gm-Message-State: AGi0PuarsgWpHyJ4Ck+jwIV8mWYoLy/RaCgaxociv/pESkyfJlhuS+Q2 1Sds0MZl5B3egTxbXbHFtLo802FlD0I= X-Google-Smtp-Source: APiQypIsY1d6/aFCJVzWkJ78i9UvQ80JxEHwK2TTif0kMPmKPIgHxPNBbyNNEK1G5z5S6SNrV9hVTQ== X-Received: by 2002:a1c:a344:: with SMTP id m65mr2992780wme.20.1586489596428; Thu, 09 Apr 2020 20:33:16 -0700 (PDT) Original-Received: from [192.168.0.2] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id y16sm1104057wrp.78.2020.04.09.20.33.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Apr 2020 20:33:15 -0700 (PDT) In-Reply-To: <20200408020913.GA3992@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::32e 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:246737 Archived-At: Hi Alan, On 08.04.2020 05:09, Alan Mackenzie wrote: >> I will shut up about it now (saying it twice it plenty), but I am pretty >> confident saying that if you manage to migrate to s-p-f, file opening >> time will go down. > > I'm sure it would. If file opening time were really a concern, a hybrid > algorithm would perhaps be the best way: apply the text properties first > in a lazy fashion, and thereafter treat them with care, as CC Mode > currently does. s-p-f would help with the first step, and as for "treating them with care", it would be good for us all to see how much of that is really needed. Improving syntax-propertize is not out of the question, and it might benefit several major modes, not just the CC collection. > But this would merely transfer the start up time to the > time taken in early scrolls forward. Not really. The start up scans the whole buffer, doesn't it? The early scrolls forward would still scan only a fraction of it. >> Performance while typing is likely to improve too, at least when the >> same buffer is not shown in another window, many thousand lines later. > > What makes you think this? Inserting characters can alter the syntax state of the whole buffer. At least that's true for some of them. Full buffer scan sounds inevitable in those cases. >> "Considerable enhancement" can also be a part of that discussion. > > The syntax-propertize-function mechanism works by erasing ALL > syntax-table properties after a change point, then reapplying them > lazily. That's not right. It only erases syntax-table properties in a chunk before calling syntax-propertize-function on the same range of positions. IOW, is overwrites them lazily as well. > Considering that s-t properties have an overwhelmingly local > effect, this is very wasteful of processor time. It would have been. As you can see, it's not a difficult problem to fix, even if it were still present. > Consider, for example, editing within a large C++ raw string, a common > occurrence. You yourself reported as a bug sluggish performance here in > mid 2016. The cause was erasing too many s-t text properties at a > buffer change. I think we were talking about 1 second per typed > character in the scenario you gave. There are typically lots of these > properties in a raw string, in particular on " characters. I'm pretty sure I have thought of that example because it's an instance of a syntax problem that's easy enough to solve within syntax-propertize-function framework. > Consider(2) a C++ template: excusing my C++ syntax knowledge, type in > > template class foo < bar, baz >= bar> > > , perhaps typing in the odd newline inside the template (a common > occurrence), or nesting further templates inside it (also a common > occurrence). Note how the parenthesis text properties are added and > removed as you type. All these modification are necessary, and they are > largely _before_ the point of insertion, not after it. The current implementation of applying these properties can probably be transferred into a syntax-propertize-function with only modest changes. >> Some scenarios can become slower, that's for sure. But the more common >> ones can get faster. We won't know until we try. > > Trying would be a _lot_ of work. How is one to handle the common > example scenarios above? Stefan has offered to help. And I'm sure he could answer the follow-up questions much better than I. > Well, you'd have to enhance the > syntax-propertize-function with a means of determining a start position > for erasing s-t props, and also a stop position. The real-world uses of s-p-f out there already solve syntax problems of comparable complexity. And move the start position, among other things. > Once you do that, > you're effectively doing what CC Mode currently does, so where's the > speed advantage coming from? From doing things more lazily, is how I see it. But I'm not an expert on CC Mode architecture. Among other benefits, moving it to a standard-ish framework like s-p-f could (possibly) simplify its code, as well as make it more approachable for other developers already familiar with how most other major modes are written. So far I wouldn't even know where to start fixing bugs in it, and IMHO CC Mode currently has bus factor = 1. It's not great for its future. I suspect it's not ideal for you either. Simply collaborating with one other developer on an overhaul project (whether it succeeds or not; perhaps partially) can improve on that. Cheers.