From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Emacs design and architecture. How about copy-on-write? Date: Fri, 22 Sep 2023 10:48:46 +0000 Message-ID: <87bkduxz3l.fsf@localhost> References: <87sf7fc7kd.fsf@dataswamp.org> <834jjuk68t.fsf@gnu.org> <87cyyhc7uu.fsf@dataswamp.org> <83ttrsg9nx.fsf@gnu.org> <83h6nrg4eg.fsf@gnu.org> <83v8c7elan.fsf@gnu.org> <877conk5ny.fsf@localhost> <83ttrreeu0.fsf@gnu.org> <87bkdzeas1.fsf@localhost> <83cyyfe5l8.fsf@gnu.org> <87led2o0nb.fsf@localhost> <83ttrqcpfb.fsf@gnu.org> <877comnv4a.fsf@localhost> <83fs3ackrq.fsf@gnu.org> <87ttrp89bx.fsf@localhost> <83led1aqnq.fsf@gnu.org> <87v8c3zun7.fsf@localhost> <83r0mr8w0j.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3302"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, incal@dataswamp.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 22 12:48:40 2023 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 1qjdiC-0000fw-3n for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Sep 2023 12:48:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qjdhM-0006FM-MK; Fri, 22 Sep 2023 06:47:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjdhB-0006El-Sb for emacs-devel@gnu.org; Fri, 22 Sep 2023 06:47:38 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qjdh8-0003Ab-84 for emacs-devel@gnu.org; Fri, 22 Sep 2023 06:47:36 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 7C2F9240027 for ; Fri, 22 Sep 2023 12:47:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1695379651; bh=BkQfSkHKSXsQHwks64AhtN9elrij0CY1pbI4+FNRF4g=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=cpUht7P/5Fx2bXU4LfEPgVBl66EX/K+k9+ELq3X3lW+bA9AT9V33bzhA1lwUSJas7 W4SCzCPxf7bkGvHGdOFF97Ley/B41WIJmAWm3jspSoo/bkoVRGdyLoEZ4S2lAksXjY P5msW08GlAZxiywNSToUfbWwh7IKkTPBTVb1ZZpW6Ren6xjyhelq9bqJkipdDsud0u 6m+Xe1q2veIbVkCHNtIkzD5EXRs3+4KgG3/Xomo6imgsqKQ0D/eGgsK3ZKB2L4XcWD 2whHX0kaDwDwI3LpKzVp62uB3wUZLuAMGx1Rq7ZNAEBoW3AcP6qYUjs5UWgkUzcVfl /9cKx2LEaxYMQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RsTVp2qKJz9rxL; Fri, 22 Sep 2023 12:47:30 +0200 (CEST) In-Reply-To: <83r0mr8w0j.fsf@gnu.org> Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310948 Archived-At: Eli Zaretskii writes: >> May you point to the xdisp.c function that is being slow? > > The basic iteration and layout calculations are slow because (a) they > must examine every character between point A and point B to figure out > the relative position of these points on the screen, and (b) because > this examination can only go forward, not back (so to go back, we must > "jump" very far back, and then go forward). In other words, processing a single window is being slow. The question now is whether processing the whole window can be split into multiple independent chunks. If it can, such processing can run in parallel. >> Ok. But is it possible to redisplay the whole frame without ever calling Elisp? > > Probably not "without ever", but why is it important in this context? > Most of the processing is in C, not in Lisp. My point is that any time we have to run Lisp during redisplay, without async Elisp threads, we have to acquire global lock first, which will degrade concurrency. I am not sure how bad the degradation will be. >> Again, not always. I do not think that the _initial_ goal should be >> making every aspect of Elisp working asynchronously without >> interlocking. We certainly want all Elisp to work in threads, possibly >> with global lock. But if we get at least some part of useful Elisp to >> run truly concurrently, it will already be a win. > > Not if we want to run the existing Lisp programs in threads with > minimal or no changes. Because Lisp programs we have now require > display and user interaction all the time, whether by themselves or by > lower-level subroutines they call. Sure. _existing_. What I have in mind is programs specifically written to take advantage of concurrency. Just to address common performance bottlenecks. >> I think you misunderstood. I did not mean calling GNU grep. I meant >> calling M-x grep - Elisp code searching across many Emacs buffers. It >> would be useful if such code could run concurrently. > > It will be much more useful if it could also show the hits as it runs, > instead of requiring the user to wait till it finishes. Maybe. But reducing the overall waiting time at the cost of not seeing the progress is an OK compromise, IMHO. >> Another example is org-agenda that is running a large number of regexp >> search across many buffers. Some real-world users search across as many >> as 500 buffers, with results accumulated into agenda. It would certainly >> be useful to run that regexp search concurrently, in multiple buffers at >> once. Or maybe even on several regions of a single, large buffer. > > And you never want to show the accumulated agenda as it is > accumulated? Yes. Because part of the fontification is performed at the very end, when everything is accumulated. >> I agree here. But do note that the interest (and some trial code by Po >> Lu) so far has been focused on Elisp threads. > > I'm quite sure people who disregard the display when they are talking > about concurrent Lisp threads are going to repeat the same mistake we > made with the existing Lisp threads. We must learn from past > experience if we want to succeed. What about addressing the existing problems with cooperating Lisp threads then? -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at