From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Pittman Newsgroups: gmane.emacs.devel Subject: Re: `process-send-*` performance seems ... bad? Date: Wed, 19 Jun 2019 14:02:34 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d79780058bb10a9e" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="71414"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 19 20:04:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hdewx-000IRT-8u for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2019 20:04:47 +0200 Original-Received: from localhost ([::1]:40950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdeww-0003vs-4O for ged-emacs-devel@m.gmane.org; Wed, 19 Jun 2019 14:04:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56782) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hdevU-0003Yi-OR for emacs-devel@gnu.org; Wed, 19 Jun 2019 14:03:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hdevT-000241-HV for emacs-devel@gnu.org; Wed, 19 Jun 2019 14:03:16 -0400 Original-Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]:33552) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hdevR-00022P-FG for emacs-devel@gnu.org; Wed, 19 Jun 2019 14:03:15 -0400 Original-Received: by mail-lf1-x129.google.com with SMTP id y17so352476lfe.0 for ; Wed, 19 Jun 2019 11:03:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iD1AjUKmmzLMBRBwKYif0zME4y3ZahpQJH+hxmsGq/0=; b=OMKgyyBRsflCYWyATklLGE/+lW87OELRkYkFdxwbAS385Rs+H0zeaVORbRI9fdAEZb Ck9gaaqcdUyhXwZwHgrC/zxeS7PQD05l2G/zU8vhwbqIoN9fTGKOCuFi5Y8g9rCngjYX MKRf9FeOEww5nhhBc3Z/CcnxwJyZGR9ySm6o0W7up0XUopRGCQbgJnjSS3zuiP2PmjND s83+m2E9CSK+pRevUYfWreL50gR/ioJHxSKOl47JUCVX9/RuknyXzcHxCoLYDe6RASiC tSlywItGZohSu84B8xMRsigRmRrCmF9Infzi0Kr9ktgTWSTgkEr1WHO8AI/XrwjYvBzV CfRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iD1AjUKmmzLMBRBwKYif0zME4y3ZahpQJH+hxmsGq/0=; b=hFX3kPdGcG2uZWy6VCS1E1PXj1/UfukF3Iqd6Kwp7fJFsP4W78otpYdxGyNqcZxCoF A6tWGq7JCNzkP+5Kt0UVGjeaep51TQFDTFvDzEZoVnTHQg0JfUAVZ3eEeN0SzDyxBHhs DQ1rHZ3Cv0IRI+coAqVwAMl1FG/Ae6Dj5ugwoEBzofg2342jCnBQReei2zaaBuFDNwi/ HlVhuiJiroyELKJSyzZeKL0mz45dKFh4EW2IitLdct4t+crhomMjbIGzwPTk7cZV3FOF 1kOsQXURLOdhtecFFzdb3h1q3aHA2QCPJnctoBV7boWxURLWH7HXi2PDPAxt0PIk3tsr A+TQ== X-Gm-Message-State: APjAAAU4XF1zEgkLr12qZrOzwtXYpxnxuvHbkOsHzZBxhZZzOi3yFjvX JsD6bjsXHv6guZMdgWILmJm2j5LvM/1cvo7/qiHQng== X-Google-Smtp-Source: APXvYqz/U8fWKdI0BlSzY/8qpoCDzfTNcT0YivAv6qJVTgQE0x+NrDRlcvLpzcyeP6R6QAHxbLETcfxfMQXbnOqTcG4= X-Received: by 2002:a19:4f50:: with SMTP id a16mr1493473lfk.24.1560967390899; Wed, 19 Jun 2019 11:03:10 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::129 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:237929 Archived-At: --000000000000d79780058bb10a9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, no, that is running locally =E2=80=93 the call to make-process is not u= sing file handlers, and the purpose of setting that default directory was to ensure that it didn't. That said, I retested with `(default-directory (expand-file-name "~"))` there, and performance is identical: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pass 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D write-with-temp-buffer: 5.8827s with 0 GCs taking 0.0000s: (5.882696 0 0.0) write-with-two-calls: 2.4786s with 0 GCs taking 0.0000s: (2.478616 0 0.0) write-with-one-call: 1.9073s with 0 GCs taking 0.0000s: (1.907256 0 0.0) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pass 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D write-with-temp-buffer: 5.6867s with 0 GCs taking 0.0000s: (5.686659 0 0.0) write-with-two-calls: 2.2408s with 0 GCs taking 0.0000s: (2.240782 0 0.0) write-with-one-call: 1.8802s with 0 GCs taking 0.0000s: (1.8801780000000001 0 0.0) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pass 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D write-with-temp-buffer: 5.7305s with 0 GCs taking 0.0000s: (5.730538999999999 0 0.0) write-with-two-calls: 2.3394s with 0 GCs taking 0.0000s: (2.339416 0 0.0) write-with-one-call: 1.9350s with 0 GCs taking 0.0000s: (1.9350479999999999 0 0.0) On Wed, Jun 19, 2019 at 10:58 AM Noam Postavsky wrote: > On Tue, 18 Jun 2019 at 17:55, Daniel Pittman > wrote: > > > ] cat obarray.data > in & wc < out & time fzf -f "hook mode" < in > out > ; wait > > > The code behind those results is attached > > (let ((default-directory > > "/gssh:slippycheeze.c.googlers.com: > /google/src/cloud/slippycheeze/work/google3/production/storage/chronicle/= ") > > It looks you're running locally in the shell case, but over TRAMP in > the elisp case. I imagine that could have a pretty large effect on > timing. Is there a reason for binding default-directory like this? > --000000000000d79780058bb10a9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, no, that is running locally =E2=80=93 the call to make= -process is not using file handlers, and the purpose of setting that defaul= t directory was to ensure that it didn't.

That said,= I retested with `(default-directory (expand-file-name "~"))` the= re, and performance is identical:

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D pass 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
write-with-temp-bu= ffer: 5.8827s with 0 GCs taking 0.0000s: (5.882696 0 0.0)
write-with-two= -calls: 2.4786s with 0 GCs taking 0.0000s: (2.478616 0 0.0)
write-with-o= ne-call: 1.9073s with 0 GCs taking 0.0000s: (1.907256 0 0.0)
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D pass 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
write-with-t= emp-buffer: 5.6867s with 0 GCs taking 0.0000s: (5.686659 0 0.0)
write-wi= th-two-calls: 2.2408s with 0 GCs taking 0.0000s: (2.240782 0 0.0)
write-= with-one-call: 1.8802s with 0 GCs taking 0.0000s: (1.8801780000000001 0 0.0= )
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D pass 3 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3Dwrite-with-temp-buffer: 5.7305s with 0 GCs taking 0.0000s: (5.73053899999= 9999 0 0.0)
write-with-two-calls: 2.3394s with 0 GCs taking 0.0000s: (2.= 339416 0 0.0)
write-with-one-call: 1.9350s with 0 GCs taking 0.0000s: (1= .9350479999999999 0 0.0)


On Wed, Jun 19, 2019 at 10= :58 AM Noam Postavsky <npostavs@gm= ail.com> wrote:
On Tue, 18 Jun 2019 at 17:55, Daniel Pittman <slippycheeze@google.com> w= rote:

> ] cat obarray.data > in & wc < out & time fzf -f "h= ook mode" < in > out ; wait

> The code behind those results is attached

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (let ((default-directory

"/gssh:slippycheeze.c.googlers.com:/google/src/cloud/slippycheeze/work= /google3/production/storage/chronicle/")

It looks you're running locally in the shell case, but over TRAMP in the elisp case. I imagine that could have a pretty large effect on
timing. Is there a reason for binding default-directory like this?
--000000000000d79780058bb10a9e--