From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: read-process-output-max Date: Wed, 31 Mar 2021 19:05:59 -0400 Message-ID: References: <87r1jxd3d8.fsf@gnu.org> <8e549f23-db75-2ef1-4399-0fb52e5efa6f@gnu.org> <87zgykn5qc.fsf@gnus.org> <83sg4ckbfw.fsf@gnu.org> <87mtukn463.fsf@gnus.org> <83o8f0kaoj.fsf@gnu.org> <83mtukk9b3.fsf@gnu.org> <2e968b98-2264-03e7-d0b2-5570c94b6fb7@gmail.com> <838s64k3xk.fsf@gnu.org> <8260671e-df0a-e471-79fb-82f80e11696a@gmail.com> <837dlok1zj.fsf@gnu.org> <83zgyjj1yf.fsf@gnu.org> <83zgyjgsar.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="19477"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, raman@google.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 01 01:07:31 2021 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 1lRjvv-0004xp-D3 for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Apr 2021 01:07:31 +0200 Original-Received: from localhost ([::1]:59212 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRjvu-0003UZ-Dx for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Mar 2021 19:07:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49976) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRjua-0002wQ-SE for emacs-devel@gnu.org; Wed, 31 Mar 2021 19:06:08 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:43805) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRjuV-0004o5-OQ; Wed, 31 Mar 2021 19:06:07 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 807054415D5; Wed, 31 Mar 2021 19:06:02 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D5CFE4415B9; Wed, 31 Mar 2021 19:06:00 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1617231960; bh=HtuIF5+K4Qq7Poe1NYnE4e/hvR+v8iOVuVbr8gaNydU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OYuWObqcpE9R/jV9/dxKznTrImuWwd5tRBv7F9BEkBIgn9RIGbP3MOo1d7DiEAjM1 B1wrekQid6qX7/XBJ7ffRH+nS7rkX/tQZuNwg0BbVgzW1V2YBectVZv10AFfFYdIgA Eoj9HjD+cyS8tAIuhC9AaULJGiiwZtxXbjocVXbAqH35fk7jv7CT+1RzXDsEsMgHj4 IqKBXszLhh0cpQNJUpEh4nEnbZ7+z0gI8CD+H0oKjtAiF0DG3fWmghrUdFO2hrLK44 pZ+gc0kQqSmBed3dcFC2eaEpBVq4tqaYeQ+1StWJl6sCjyLkYvFJk5tJZA34lTjDKE Hs5HVU5J7P1ug== Original-Received: from alfajor (104-222-126-84.cpe.teksavvy.com [104.222.126.84]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EB3FE120249; Wed, 31 Mar 2021 19:05:59 -0400 (EDT) In-Reply-To: <83zgyjgsar.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 31 Mar 2021 20:13:32 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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.23 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:267227 Archived-At: >> I understand there is a per-chunk overhead which pushes towards a higher >> value, but I'm not sure what factors are pushing towards smaller values. > Values larger that some threshold will cause us use malloc instead of > alloca, that's one reason to use smaller buffers for performance > reasons. That's indeed a good reason not to push the limit to far up, indeed. > Another potential issue, in programs that display the arriving stuff > as it is received, is that showing the text in small chunks is > generally better (UX-wise) than blasting a 1MB chunk of text to the > screen in one go. If 64kB already arrived, will part of the result really reach the eyes of the user faster if we process them as 16 chunks of 4kB or do we skip redisplay between the chunks (just like we skip redisplay when there are pending input events)? > The effect of the value was never studied in detail, and so the > optimal value could be different from the default. The doc string > says what it says to prevent people from getting themselves into > trouble when they don't really need to change the value for their > application: after all, the default value was used for many years, and > should be considered safe enough. Makes sense, indeed. It might be worth having people play with the value for a while (and not just for bulk-bandwidth tests but also for interactive use like `M-x shell`, `M-x compile`, `M-x grep`, including with largish outputs) and report back. I just put (setq read-process-output-max (max 65536 read-process-output-max)) into my init file, and I'll see if I notice a difference. [ BTW, I think a value >=32kB would be desirable since it avoids breaking UDP datagrams. ] Stefan