From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karthik Chikmagalur Newsgroups: gmane.emacs.devel Subject: Re: Understanding filter function calls Date: Thu, 27 Jul 2023 14:08:23 -0700 Message-ID: <87pm4d12rc.fsf@gmail.com> References: <87y1j5vp3y.fsf@gmail.com> <96ad3a89-a0bd-6f8a-6251-d3f2f201e4f7@vodafonemail.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5037"; mail-complaints-to="usenet@ciao.gmane.io" To: Jens Schmidt , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jul 27 23:45:11 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 1qP8nG-00013Y-PH for ged-emacs-devel@m.gmane-mx.org; Thu, 27 Jul 2023 23:45:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qP8Du-0003p3-Nq; Thu, 27 Jul 2023 17:08:38 -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 1qP8Dp-0003oj-3h for emacs-devel@gnu.org; Thu, 27 Jul 2023 17:08:34 -0400 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qP8Dn-0005hL-0V for emacs-devel@gnu.org; Thu, 27 Jul 2023 17:08:32 -0400 Original-Received: by mail-pf1-x432.google.com with SMTP id d2e1a72fcca58-686f38692b3so1085574b3a.2 for ; Thu, 27 Jul 2023 14:08:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1690492106; x=1691096906; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :from:to:cc:subject:date:message-id:reply-to; bh=ExWZnU8HR81CJg4d9W+upJ4WGZ4WDGsgbs3kcVsbTmk=; b=E4LXfk278d4OcEVn9OXVqwYwk95a0VL9MVboukBlCOLIMi25x5t+/igR0Me4M6WvdJ e56e0OOWBRwq9B13omwLaxy5LIUvtVtwN6mYaQSY6wvzdBxEYwaTW6laq9/sWSLkdEeH A1g1rEWaZOh3Dys87inTjpyFYP/tY/YXKAaE6qiIrmCez3xgwbJVZvxKREir3DEvYeid ilKRLjatknAhPPcrXsOiQt1XldzJQj0Kg2a4oQ4Z9Mu9sl2mi1Wg3NAo+Q0qZ6Kvb1bS 8q5HuIMdejJ239liPcwwLN6g3RITPAUrVlvku837OXhnjJM+ZXiU8n+xYijPbt7sC8+X YA/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690492106; x=1691096906; h=mime-version:message-id:date:references:in-reply-to:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ExWZnU8HR81CJg4d9W+upJ4WGZ4WDGsgbs3kcVsbTmk=; b=daFTszCkiQDzYoMk2+isPNqqwnFsnRZcu7nyDVSIxEmqVklGyMTMhYO7u1oIh0nSRL ihrrawA+X6i1nnRBI+lQ47OF4iOqR9duCILydfytAaGSKkR+vprEx5S6dO230hQORVJ8 1534y6eO3kfME4+ZqXUngJwtJh05PrRgcpkUI5mOghXSbiCz9+Rz9UwlVuoZk+lEujEs gNm6dk97P1/salMSAagrvN3ZrIsssrbMZKRfQaM57oS+CjyRBoF/4dHbbkoMs90CZjxZ S7JMsMF0bFC1Jg1+6uyRYOTSqPxfHyUmlO0BaNLkSvrSvwYhUE75fx4SEKKsbWR3ZWgK sKNQ== X-Gm-Message-State: ABy/qLYKfwecInkViFCVpN2J6TMXESCyusNd39o8qr1eSSd3bNX6lhpL uANy3Ib27OTDONAjijSI3+sQBUkmAkg= X-Google-Smtp-Source: APBJJlH86VGBC/BoUODoCIAK5D2ZpvOBDAzbAu9c+Z6oufDIU3r2yWbYIaROUuUtZU2DO1GEQtTMWA== X-Received: by 2002:a05:6a00:181c:b0:686:5a11:a434 with SMTP id y28-20020a056a00181c00b006865a11a434mr401468pfa.3.1690492105860; Thu, 27 Jul 2023 14:08:25 -0700 (PDT) Original-Received: from localhost (ip184-189-240-75.sb.sd.cox.net. [184.189.240.75]) by smtp.gmail.com with ESMTPSA id a23-20020a62bd17000000b00676bf2d5ab3sm1880980pff.61.2023.07.27.14.08.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Jul 2023 14:08:25 -0700 (PDT) In-Reply-To: <96ad3a89-a0bd-6f8a-6251-d3f2f201e4f7@vodafonemail.de> Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=karthikchikmagalur@gmail.com; helo=mail-pf1-x432.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308176 Archived-At: > ... seems that TeXLive 2023 creates differently sized chunks of output? > Could you try to buffer these using, for example, "dd", to see whether > that makes a difference? Thank you for the suggestion. The problem appears to be simpler than varying chunk sizes. I had a closer look at the stdout from the two versions of dvisvgm and it turns out they are not, in fact, identical. On a large Org file, TeXLive 2023's dvisvgm stdout is 2521 lines to TeXLive 2022's 1520. This difference is explainable by some extra information that dvisvgm prints per generated SVG image in the former case: TeXLive 2023: -------8<-------- processing page 2 computing extents based on data set by preview package (version 13.1) width=5.520849pt, height=6.944447pt, depth=0pt graphic size: 5.520849pt x 6.944447pt (1.940357mm x 2.440694mm) output written to test-000000002.svg -------8<-------- TeXLive 2022: -------8<-------- processing page 2 graphic size: 18.524351pt x 10pt (6.510565mm x 3.514598mm) output written to test-000000002.svg -------8<-------- Multiply the above blocks by 600, and that explains the large difference in the sizes of the stdout. It does not take any longer for the filter function to run on each invocation. The problem is that The filter in Emacs is called with about 4KB of new text every time, and these calls are spaced out evenly in time, so Emacs takes longer to get around to parsing the stdout with TeXLive 2023. The dvisvgm process is thus bottlenecked by Emacs. I can imagine a few different ways to fix this, but I don't know how to do them: 1. Reduce the duration between successive calls of the filter function. Is this configurable in Emacs? I don't see anything relevant in the manual sections on accepting output from processes or filter functions. 2. Enlarge the buffer or "pipe" connecting dvisvgm to Emacs. This stream buffer appears to be set to 4KB. Since dvisvgm produces far more output (to stdout) than this between two successive instances of Emacs accepting process output, widening the pipe should relieve this pressure. I tried tweaking `read-process-output-max' but this doesn't help. 3. Get dvisvgm to generate less verbose output. Unfortunately this is not configurable at the level of granularity that we need. We can't turn it off completely either since we rely on certain strings in the process stdout to update the LaTeX preview state in Org buffers. Any ideas on how to avoid this throttling would be appreciated. Karthik