From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Major modes using `widen' is a good, even essential, programming practice. Date: Mon, 08 Aug 2022 14:39:56 +0300 Message-ID: <837d3jvu9f.fsf@gnu.org> References: <6ae35c9306ade07b4c45@heytings.org> <835yj4xhh7.fsf@gnu.org> <83y1w0w0gk.fsf@gnu.org> <83pmhcvugm.fsf@gnu.org> <83czdbwjfr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14088"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gregory@heytings.org, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 08 13:41:54 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 1oL18s-0003Ug-IO for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 13:41:54 +0200 Original-Received: from localhost ([::1]:36504 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oL18r-0001TQ-Df for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Aug 2022 07:41:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL17D-0000jm-Ea for emacs-devel@gnu.org; Mon, 08 Aug 2022 07:40:11 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43450) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL17C-0004vN-Bi; Mon, 08 Aug 2022 07:40:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/DGua8/PIovKtx55t1ZZFXnzP7KjHq5PrLZCGnzoikU=; b=KbMWBiICOFuP JHhs4cEN/uc4qWUJt3XVHghAs4MMjlen2jFC8DBLoTE2epbOVA/IFdva1N4wNzQYwR1jk+yFxsitj 5E/rPZ2N1IpNxnuejNgSbmHYYmd55I9hVC4HLO0Y6yThZ1QO0iYFzjrxA6KJzJJceJz0BxZJvSDR4 E7YwkCxAWj1it0kROKxYlfA/Xsms07SGmb8LO6+RTzW83usg3WxzsjISUq6i6kGffiX6y2vCXqxWp ThmeyWNIHKUHRxLHxvj5JA7QGfbqCzHJQB/Zz6lXcEfLVeB4JEa6Xoz1K5Bx8kpDwz1dDl75P4z7U Pwre32uSCryN+8LX9lixgA==; Original-Received: from [87.69.77.57] (port=1845 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oL17B-0004OM-QG; Mon, 08 Aug 2022 07:40:10 -0400 In-Reply-To: (message from Alan Mackenzie on Mon, 8 Aug 2022 09:58:29 +0000) 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:293254 Archived-At: > Date: Mon, 8 Aug 2022 09:58:29 +0000 > Cc: gregory@heytings.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > > > 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. I thought the facts and findings in this and related discussions recently have shown beyond any reasonable doubt that we do. > > > 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. I guess you have just explained to yourself why processing all of the buffer is unscalable? Which was my point all the way. > Some things take a certain amount of time, and there's nothing we can do > about it. Of course, there's something to do: do less of that! This is exactly the main idea behind narrowing, and any other similar limitations. For example, bidi.c stops looking back for a paragraph's beginning if it didn't find one within a predefined number of lines. Failure to find and process the paragraph's beginning could potentially produce an utterly incorrect display of bidirectional text, but we do that anyway. Why? because it's unreasonable to slow down redisplay to a crawl for the benefit of very rare situations. Why cannot CC Mode do something similar, with a similar justification? > > 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? Consider it open. I'm sure I complained about this more than once already, and yet here we are. > > 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. Well, I _am_ talking about long lines. Because you insist on the necessity to go far back even in that case. When we solve the long-line case, we can consider the large-buffer case, and perhaps even find that the same solution fits both.