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: Understanding filter function calls Date: Sun, 30 Jul 2023 08:14:37 +0300 Message-ID: <83wmyikmki.fsf@gnu.org> References: <87y1j5vp3y.fsf@gmail.com> <96ad3a89-a0bd-6f8a-6251-d3f2f201e4f7@vodafonemail.de> <87pm4d12rc.fsf@gmail.com> <835y64lhd8.fsf@gnu.org> <87cz0b1zmw.fsf@gmail.com> <83sf97i7ak.fsf@gnu.org> <877cqi1hym.fsf@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6189"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jschmidt4gnu@vodafonemail.de, emacs-devel@gnu.org To: Karthik Chikmagalur Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 30 07:40:54 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 1qPzAj-0001Q6-5S for ged-emacs-devel@m.gmane-mx.org; Sun, 30 Jul 2023 07:40:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qPylQ-0004Gw-5i; Sun, 30 Jul 2023 01:14:44 -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 1qPylL-0004GX-Fo for emacs-devel@gnu.org; Sun, 30 Jul 2023 01:14:40 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qPylJ-0005iF-Is; Sun, 30 Jul 2023 01:14:39 -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=zao4UgQN1TqQqOkjNbFvFQfZlyVcYlp+HBTImJ4MBQA=; b=VvwOQFvWxuZZ xxdhzDh9n+C/PkSjrTyLhwI/jCtBbnU/uf1uMKP1XgVST5dhDigexKZ+xbm/wpPQy65K7rCZqARV3 BFPvGQ31/R2qvAxypStixzwxN1/8MIwR5d66QwJgB8mAxlbhl/nMGl4deLUhR5fw+a/LZbiQKOILV OdaxUq/dtZXFNSo88ll/sOuXR6Vrj+HqybO14CvzfY0uEPKPu4HeVrYaUiwNBitAm3gGCZDN8eeIu piFuH6oSLNEIPdDzj38J6Z7vQPAfUa/zCdgmLS5J9g38v51DnLfCMhPOhu1ksk/57LESiEfCUdSaC ms7cujABhIB8weW3q462Mg==; Original-Received: from [87.69.77.57] (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 1qPylJ-0002m3-0F; Sun, 30 Jul 2023 01:14:37 -0400 In-Reply-To: <877cqi1hym.fsf@gmail.com> (message from Karthik Chikmagalur on Sat, 29 Jul 2023 15:16:49 -0700) 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:308204 Archived-At: > From: Karthik Chikmagalur > Cc: jschmidt4gnu@vodafonemail.de, emacs-devel@gnu.org > Date: Sat, 29 Jul 2023 15:16:49 -0700 > > 1. A pty connection + adaptive-read is the slowest (by a fair bit). All > other combinations are equally fast. It is a general recommendation to use pipes when the subprocess produces large amounts of output, and Emacs doesn't need to emulate interactive behavior vis-a-vis that subprocess' program. PTYs are less pertinent for high-throughput applications. > 2. Despite the value of read-process-output-max, a pty connection calls > the filter function with at most 4 KB of data most of the time. I think this is a limitation of the Linux kernel's implementation of PTYs. > 3. With a pipe connection, we indeed see reads of up to > read-process-output-max (64 KB in my tests). FTR: if someone has to do something similar on MS-Windows, they will need to enlarge the value of w32-pipe-buffer-size accordingly. > >> But I was able to use Emacs normally (typing, calling M-x etc) when the > >> previews were being updated, which is great. So I'm not sure what the > >> performance implications are here. > > > > You don't want to rewind the long history of this and re-live all the > > issues we experienced and investigated before we settled on the > > current default. If you can solve this particular problem by binding > > the variable to nil around the code which invokes dvisvgm, that is all > > I suggest doing. > > I agree that it's not important, I was just curious since I didn't > notice any immediate issues. the issues are not always immediate, and don't became apparent until you see enough subprocesses of different kinds, throughputs, and behavioral aspects. In the long history of this variable, its default changed at least twice, AFAIR.