From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Philip K." Newsgroups: gmane.emacs.devel Subject: Re: Emacs HTTP libraries [was: Re: How to contribute new package to GNU ELPA?] Date: Tue, 22 Dec 2020 17:59:19 +0100 Message-ID: <87mty5g4k8.fsf@posteo.net> References: <83mty5rfq5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20920"; mail-complaints-to="usenet@ciao.gmane.io" Cc: adam@alphapapa.net, rms@gnu.org, arthur.miller@live.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 22 18:02:18 2020 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 1krl3C-0005Jh-CE for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Dec 2020 18:02:18 +0100 Original-Received: from localhost ([::1]:45274 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1krl3B-0001CU-9Q for ged-emacs-devel@m.gmane-mx.org; Tue, 22 Dec 2020 12:02:17 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56606) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krl0S-0008Mz-Pt for emacs-devel@gnu.org; Tue, 22 Dec 2020 11:59:28 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:58176) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1krl0P-0002Y0-8E for emacs-devel@gnu.org; Tue, 22 Dec 2020 11:59:28 -0500 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 890D9160063 for ; Tue, 22 Dec 2020 17:59:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1608656360; bh=BORQGtwOswELaJyFn3KTwCZh9L6+m2duns6dO/ZbmLk=; h=From:To:Cc:Subject:Date:From; b=BG6jFrVf5B1N7O1CZtkBNL2DU54NH5p/lI0B9P4jsHnR6c8wjv/07HECOV/OritXF DUYl9zY0piXervpM3YAEfB3Z1HO9NqTJHYi2OgZeIhUuprqwpAcnl/xHUwpd46Yo+K 2e1PVxMJCfxc5bG0SK1XaIvdnDlfsNzqhOQ6ZAxXjH7BEFftCW4rFRPdaEupqhp79w 0VxdsXnOwk7jiagirg/kXAHJaBOD8+CVDu+IDd6JpntqbqnW5zxER6NcpIRx3OQAJ5 D05Y0DviwJcRfqucUZZadkIfdJeSZRdA+Jtx5OpUsrUVrIpIC9rm5yLsnjOUt3WA9/ KxcX4dc/UkJ3Q== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4D0jHC65Sjz6tmP; Tue, 22 Dec 2020 17:59:19 +0100 (CET) In-Reply-To: <83mty5rfq5.fsf@gnu.org> (message from Eli Zaretskii on Tue, 22 Dec 2020 18:02:42 +0200) Received-SPF: pass client-ip=185.67.36.65; envelope-from=philipk@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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:261511 Archived-At: Eli Zaretskii writes: >> From: "Philip K." >> Cc: arthur.miller@live.com, adam@alphapapa.net, rms@gnu.org, >> emacs-devel@gnu.org >> Date: Tue, 22 Dec 2020 11:38:31 +0100 >>=20 >> >> In that case, gnutls-negotiate seems to be the most suspicious functi= on, >> >> using over 50%-60% of the CPU time, at least on my machine. This also >> >> makes sense, as TLS sites seem to take longer to load than regular, >> >> non-encrypted ones. >> > >> > Please show the code you profiled and the fully expanded profile. >>=20 >> I sadly coudln't reproduce it, but this time the critical section looked >> something like this: >>=20 >> - url-retrieve-synchronously 212 = 52% >> - url-retrieve 149 = 36% >> - url-retrieve-internal 149 = 36% >> - url-http 136 = 33% >> - url-http-find-free-connection 135 = 33% >> - url-open-stream 135 = 33% >> open-network-stream 134 = 33% >>=20 >> when evaluating=20 >>=20 >> (url-retrieve-synchronously "http://textboard.org/sexp/prog/index") >>=20 >> in the *scratch* buffer. I used emacs -Q (GNU Emacs 27.1 (build 1, >> x86_64-redhat-linux-gnu, GTK+ Version 3.24.22, cairo version 1.16.0) of >> 2020-08-21), but I don't know why that should make any >> difference. I repeated the same test on the master branch and the >> results were basically the same (=C2=B15%). >>=20 >> Either way, this simple request took over 2.5 minutes, whereas curl >> requires a quarter of a second. Note that this is even unencrypted, so >> this is not even taking the encryption overhead into account. > > That's strange, because I get here much faster times: 0.6 sec (with 3 > GC cycles) on the first attempt, and less than 0.1 sec afterwards. Why did it take three GC cycles? benchmark-run says (130.773534384 0 0.0) and=20 (129.933227402 0 0.0) for the first two runs, and (0.044592597 0 0.0) for the third one, a bit later. > How come it's so slow on your system? I can't say for sure, but I don't think it is due to some specific local configuration. I reran the code on a university computer a few kilometres away, and the behaviour stays basically the same, even though their network is a lot better than mine. But when I ran it on a VPS in Berlin (I'm currently in southern Germany), it was a lot faster, despite probably running the same build (whatever it in the Debian Buster repository). I looked up where textboard.org is located, and it seems to be in France, or it at the very least has to pass through some Proxy in France. Another interesting observation is that connections from my home to my university are basically instantaneous using Eww, and vice versa. The Server in Berlin takes a lot longer to connect to my local network and my university server. The only exception to this rule is that eww doesn't seem to take that long to connect to my VPS. None of these effects are observable using curl. I guess this should be reported as a proper bug, instead of being discussed here. --=20 Philip K.