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: Sv: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?] Date: Wed, 31 Mar 2021 09:22:37 +0300 Message-ID: <83y2e3j102.fsf@gnu.org> 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> <35cb99a0-4350-f100-0c23-d554e6548bcc@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5971"; mail-complaints-to="usenet@ciao.gmane.io" Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 31 08:23:08 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 1lRUFv-0001Qj-Cm for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Mar 2021 08:23:07 +0200 Original-Received: from localhost ([::1]:33606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRUFu-0002jx-CO for ged-emacs-devel@m.gmane-mx.org; Wed, 31 Mar 2021 02:23:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36354) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lRUFF-0002G9-98 for emacs-devel@gnu.org; Wed, 31 Mar 2021 02:22:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:54867) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lRUFE-0007UC-LY; Wed, 31 Mar 2021 02:22:24 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4094 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lRUFD-0008Rl-Uf; Wed, 31 Mar 2021 02:22:24 -0400 In-Reply-To: (message from Stefan Monnier on Tue, 30 Mar 2021 21:08:43 -0400) 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:267208 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , emacs-devel@gnu.org > Date: Tue, 30 Mar 2021 21:08:43 -0400 > > > Not if you turn off garbage collection, indeed (except for the fact that you > > pay for it later on), but wouldn't a native library remove that GC pressure? > > Not clear. There's a good chance that the GC pressure is due to the > strings generated and passed to the process filter and then inserted in > a temp buffer. > > So there's a chance that even going through a super-efficient C library, > as long as the end result is returned via output sent to a process > filter for insertion into a temp buffer the result won't necessarily be > much better. We could add a special kind of filter that puts the text directly into a buffer, without going through a string. In that special filter, we could make arrangements to preallocate a large enough gap for that buffer, so that repeated reallocations won't get in the way, either. Then GC won't be a problem even when doing this entirely in Emacs code. But I think this all is premature optimization. We have only one synthetic use case; we should base our design decisions on more solid grounds, after looking into more uses and analyzing the reason(s) for the slowness.