From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Mon, 8 Aug 2022 09:58:29 +0000 Message-ID: References: <6ae35c9306ade07b4c45@heytings.org> <835yj4xhh7.fsf@gnu.org> <83y1w0w0gk.fsf@gnu.org> <83pmhcvugm.fsf@gnu.org> <83czdbwjfr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38237"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 11:59:51 2022 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 1oKzY6-0009my-Ql for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 11:59:50 +0200 Original-Received: from localhost ([::1]:48514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKzY5-0003iM-DF for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 05:59:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKzWu-0002zD-5u for emacs-devel@gnu.org; Mon, 08 Aug 2022 05:58:36 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:59955 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1oKzWr-0004uA-OG for emacs-devel@gnu.org; Mon, 08 Aug 2022 05:58:35 -0400 Original-Received: (qmail 68486 invoked by uid 3782); 8 Aug 2022 09:58:31 -0000 Original-Received: from acm.muc.de (p4fe1582e.dip0.t-ipconnect.de [79.225.88.46]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 08 Aug 2022 11:58:30 +0200 Original-Received: (qmail 5033 invoked by uid 1000); 8 Aug 2022 09:58:29 -0000 Content-Disposition: inline In-Reply-To: <83czdbwjfr.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:293246 Archived-At: Hello, Eli. On Mon, Aug 08, 2022 at 05:36:08 +0300, Eli Zaretskii wrote: > > Date: Sun, 7 Aug 2022 19:20:44 +0000 > > Cc: gregory@heytings.org, emacs-devel@gnu.org > > From: Alan Mackenzie > > > > > Either in the cache or in the buffer: the previous chunk was > > > > > fontified, so its end has the font-lock-comment-face. So you know. > > > > No, you don't. The buffer might be being opened by desktop in a large > > > > comment in the middle of the file. > > > You've changed the scenario, yes? > > Yes. We've got to deal with all scenarios, preferably without > > special-caseing special cases. > No one said that all the scenarios must have the same solution. I suppose not, but optimising for different scenarios would be, well, an optimisation. Do we really need it. > > > > What jit-lock/font-lock actually do at the moment is to widen, then use > > > > syntax-ppss, i.e. in effect scan from BOB. > > > Yes, and that's SLOOOWWWW! > > On my machine, with an optimised build, it takes just under 20 ms to > > parse-partial-sexp over xdisp.c (not counting any redisplay at the end). > > I don't understand any more than Dmitry does, why your unoptimised build > > is taking 25 times as long. > It doesn't help to know that some very fast machine can do this stuff > quickly enough to remain below the annoyance threshold. 20 ms is a > very long time by the current CPU speed measure: just calculate the > number of CPU cycles in that time and you will see it. We're talking about 1.2 MB here. That works out at less than 17 ns per character. Each round of the loop is a fairly sophisticated finite state machine pass. Possibly it could be optimised, but I doubt by very much. Some things take a certain amount of time, and there's nothing we can do about it. (Of course we can do things about some other aspects.) > > > > That "needing to go too far" is an instantaneous jump, not a scanning. > > > Please tell that to someone who doesn't edit C sources as frequently > > > as I do. > > Are you saying that long strings and long comments cause a particular > > slowdown in C Mode, not seen when strings and comments are all short? > I don't know what makes it slow, but it feels sluggish in even the > simplest editing operations, and font-lock updates are slow as well. How about us opening a bug report for CC Mode's speed with font-lock-maximum-decoration = 2? > > > > The string start will be in a parse-partial-sexp result somewhere. > > > > Sometimes people write long strings. They certainly write long comments. > > > Why do I have top suffer every day just because someone, somewhere, > > > might do that? I'd rather we "punish" those few people who do it > > > (rarely). > > I don't think we should punish people who write comments. I'm thinking > > of Gerd M., who was likely the writer of the comment at the beginning of > > xdisp.c. > We are still talking about long lines, yes? There are no long lines > in that commentary at the beginning of xdisp.c. I don't think we were still talking about long lines. We were talking about parse-partial-sexp on large files. -- Alan Mackenzie (Nuremberg, Germany).