X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 05 Oct 2022 11:08:02 +0000
Resent-Message-ID: <handler.58302.B.166496807825340 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 58302 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.166496807825340
(code B ref -1); Wed, 05 Oct 2022 11:08:02 +0000
Received: (at submit) by debbugs.gnu.org; 5 Oct 2022 11:07:58 +0000
Received: from localhost ([127.0.0.1]:56047 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1og2Fm-0006aa-Kg
for submit <at> debbugs.gnu.org; Wed, 05 Oct 2022 07:07:58 -0400
Received: from lists.gnu.org ([209.51.188.17]:35052)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <psainty@HIDDEN>) id 1og2FY-0006aA-24
for submit <at> debbugs.gnu.org; Wed, 05 Oct 2022 07:07:53 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40640)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <psainty@HIDDEN>)
id 1og2FT-0006le-Eu
for bug-gnu-emacs@HIDDEN; Wed, 05 Oct 2022 07:07:38 -0400
Received: from smtp-2.orcon.net.nz ([60.234.4.43]:48755)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <psainty@HIDDEN>)
id 1og2FQ-0006li-Rb
for bug-gnu-emacs@HIDDEN; Wed, 05 Oct 2022 07:07:35 -0400
Received: from [10.253.37.70] (port=58810 helo=webmail.orcon.net.nz)
by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1)
(envelope-from <psainty@HIDDEN>) id 1og2FM-0001pZ-6X
for bug-gnu-emacs@HIDDEN; Thu, 06 Oct 2022 00:07:29 +1300
Received: from ip-116-251-140-135.kinect.net.nz ([116.251.140.135])
via [10.253.37.253] by webmail.orcon.net.nz
with HTTP (HTTP/1.1 POST); Thu, 06 Oct 2022 00:07:25 +1300
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 06 Oct 2022 00:07:25 +1300
From: Phil Sainty <psainty@HIDDEN>
Message-ID: <929023db7615cc93faad294e3860ba5f@HIDDEN>
X-Sender: psainty@HIDDEN
User-Agent: Orcon Webmail
X-GeoIP: --
Received-SPF: pass client-ip=60.234.4.43; envelope-from=psainty@HIDDEN;
helo=smtp-2.orcon.net.nz
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: browse-url-emacs has always been inexplicably slow for me,
since at least Emacs 24 (but maybe just 'always'). I've just done some basic
benchmarking with: (benchmark-run (save-selected-window (browse-url-emacs
"http://www.example.com")))
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (psainty[at]orcon.net.nz)
0.7 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
0.7 SPOOFED_FREEMAIL No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)
browse-url-emacs has always been inexplicably slow for me,
since at least Emacs 24 (but maybe just 'always').
I've just done some basic benchmarking with:
(benchmark-run (save-selected-window
(browse-url-emacs "http://www.example.com")))
;; If I delete the "www.example.com" buffer after each attempt, this
;; call takes nearly 3 seconds:
(2.819470404 1 0.046148434000000016)
(2.669529036 0 0.0)
(2.837350438 1 0.02421054800000011)
;; If I retain the "www.example.com" buffer, then each retry takes
;; <0.5 seconds:
(0.374270464 0 0.0)
(0.428719681 0 0.0)
(0.476068586 1 0.044311528999999794)
;; Whereas benchmarking only `url-retrieve-synchronously':
(benchmark-run (url-retrieve-synchronously "http://www.example.com"))
;; This takes <0.25 seconds.
(0.172364234 0 0.0)
(0.24314511600000002 0 0.0)
(0.19534228 0 0.0)
;; Deleting the network connection via M-x list-processes between
;; attempts adds about 0.25 seconds for all sets of benchmarks, so the
;; network connection time is not a factor.
;; eww is also fast:
(benchmark-run (save-window-excursion (let ((eww-retrieve-command
'sync))
(eww "http://www.example.com"))))
(0.197008672 0 0.0)
(0.25098304499999996 0 0.0)
(0.28419454299999997 0 0.0)
So something to do with browse-url-emacs is taking an additional 2.5s
on top of the basic URL request -- unless the buffer already exists,
in which case it's much faster (albeit still twice as slow as the
other options).
Presumably this could be improved?
If I benchmark-progn the final (funcall func url) in browse-url-emacs
I can see that this is where all the time is spent. func is set to
`find-file-other-window'; so this is equivalent:
(benchmark-run
(save-selected-window
(let ((file-name-handler-alist
(cons (cons url-handler-regexp 'url-file-handler)
file-name-handler-alist)))
(find-file-noselect "http://www.example.com")))
(kill-buffer "www.example.com"))
If the buffer already existed, *Messages* says:
Contacting host: www.example.com:80
(0.408067329 0 0.0)
If the buffer did not already exist, *Messages* says:
Contacting host: www.example.com:80 [2 times]
File exists, but cannot be read
(2.617302471 0 0.0)
(The "[2 times]" is not on account of a previous test;
they are both generated by this single call.)
Benchmarking the end of `find-file-noselect' like so:
(benchmark-progn
(find-file-noselect-1 buf filename nowarn
rawfile truename number))
Gives me:
Elapsed time: 1.876737s (0.057295s in 1 GCs) ;; find-file-noselect-1
(2.680159853 1 0.057295379000000146) ;; the overall
benchmark-run
And that's as far as I've gone.
-Phil
In GNU Emacs 29.0.50 (build 4, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.10, Xaw scroll bars)
of 2022-07-15 built on phil-lp
Repository revision: 00eb894a56d63fad3573a53dd57c323289711512
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version
11.0.12008000
System Description: Ubuntu 18.04.6 LTS
Configured using:
'configure --prefix=/home/phil/emacs/trunk/usr/local
--with-x-toolkit=lucid --without-sound
'--program-transform-name=s/^ctags$/ctags_emacs/''
Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP THREADS
TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM LUCID ZLIB
Important settings:
value of $LC_MONETARY: en_NZ.UTF-8
value of $LC_NUMERIC: en_NZ.UTF-8
value of $LC_TIME: en_NZ.UTF-8
value of $LANG: en_GB.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
savehist-mode: t
windmove-mode: t
winner-mode: t
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr emacsbug mule-util display-line-numbers dcl-mode
tempo mm-archive message sendmail yank-media rfc822 mml mml-sec epa
derived epg rfc6068 epg-config gnus-util mailabbrev gmm-utils mailheader
mm-decode mm-bodies mm-encode url-dav parse-time iso8601 cl-extra
cl-print debug backtrace find-func benchmark shortdoc url-about
url-handlers thingatpt help-fns radix-tree help-mode dabbrev time-date
textsec uni-scripts idna-mapping ucs-normalize uni-confusable
textsec-check mail-utils gnutls network-stream url-http mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm
url-cache url-auth shr text-property-search pixel-fill kinsoku url-file
url-dired puny svg xml dom browse-url url url-proxy url-privacy
url-expand url-methods url-history url-cookie generate-lisp-file
url-domsuf url-util url-parse auth-source cl-seq eieio eieio-core
cl-macs password-cache json subr-x map byte-opt gv bytecomp byte-compile
cconv url-vars mailcap savehist windmove winner ring dired-aux
cl-loaddefs cl-lib dired dired-loaddefs advice rmc iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)
Memory information:
((conses 16 210718 27584)
(symbols 48 9278 0)
(strings 32 47429 2202)
(string-bytes 1 1030861)
(vectors 16 40826)
(vector-slots 8 595360 31429)
(floats 8 105 82)
(intervals 56 1185 0)
(buffers 992 38))
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Phil Sainty <psainty@HIDDEN> Subject: bug#58302: Acknowledgement (29.0.50; browse-url-emacs is extremely slow (and I think always has been?)) Message-ID: <handler.58302.B.166496807825340.ack <at> debbugs.gnu.org> References: <929023db7615cc93faad294e3860ba5f@HIDDEN> X-Gnu-PR-Message: ack 58302 X-Gnu-PR-Package: emacs Reply-To: 58302 <at> debbugs.gnu.org Date: Wed, 05 Oct 2022 11:08:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 58302 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 58302: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D58302 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 06 Oct 2022 12:54:01 +0000
Resent-Message-ID: <handler.58302.B58302.166506080415489 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Phil Sainty <psainty@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166506080415489
(code B ref 58302); Thu, 06 Oct 2022 12:54:01 +0000
Received: (at 58302) by debbugs.gnu.org; 6 Oct 2022 12:53:24 +0000
Received: from localhost ([127.0.0.1]:59345 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ogQNQ-00041l-88
for submit <at> debbugs.gnu.org; Thu, 06 Oct 2022 08:53:24 -0400
Received: from quimby.gnus.org ([95.216.78.240]:41330)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <larsi@HIDDEN>) id 1ogQNN-00041U-Ab
for 58302 <at> debbugs.gnu.org; Thu, 06 Oct 2022 08:53:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=hVGwlt7QlHIfTvDBW6Epjqf5Oq9tQcZgfoQ1GF05LWA=; b=qbkaBQ1F1pj7OvND8V/rXGJxLv
oYDJBYv3If7XdYjobXm2Fhmr4j7WDlzMDrowENxY9Tf8iWbMiwMac2FfO4ruifGVmZzSScc4HLE43
jw0/X3UfcDcxjr+v83nx1p1kNWy5BNAi/TPow349cUJPo2RcQeMeuiE8LJjc+UsBdkyk=;
Received: from [84.212.220.105] (helo=downe)
by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92) (envelope-from <larsi@HIDDEN>)
id 1ogQND-00030J-Ut; Thu, 06 Oct 2022 14:53:14 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <929023db7615cc93faad294e3860ba5f@HIDDEN> (Phil
Sainty's message of "Thu, 06 Oct 2022 00:07:25 +1300")
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
X-Now-Playing: Curve's _Still in a Dream (3)_: "Ten Little Girls"
Date: Thu, 06 Oct 2022 14:53:11 +0200
Message-ID: <87edvlxgeg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: Phil Sainty <psainty@HIDDEN> writes: > If the buffer
did not already exist, *Messages* says: > Contacting host: www.example.com:80
[2 times] > File exists, but cannot be read > (2.617302471 0 0.0)
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Phil Sainty <psainty@HIDDEN> writes:
> If the buffer did not already exist, *Messages* says:
> Contacting host: www.example.com:80 [2 times]
> File exists, but cannot be read
> (2.617302471 0 0.0)
I can reproduce this, too. I think it's likely that the delay is coming
from the error message (which is a misleading error message). There's
probably a "sleep-for 2" after displaying the error message?
There's a bug report in debbugs somewhere about fixing the error
message, but I can't find it now.
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 06 Oct 2022 23:26:01 +0000
Resent-Message-ID: <handler.58302.B58302.16650987332141 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.16650987332141
(code B ref 58302); Thu, 06 Oct 2022 23:26:01 +0000
Received: (at 58302) by debbugs.gnu.org; 6 Oct 2022 23:25:33 +0000
Received: from localhost ([127.0.0.1]:33833 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ogaFB-0000YT-6G
for submit <at> debbugs.gnu.org; Thu, 06 Oct 2022 19:25:33 -0400
Received: from smtp-1.orcon.net.nz ([60.234.4.34]:57831)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <psainty@HIDDEN>) id 1ogaF7-0000YE-Qn
for 58302 <at> debbugs.gnu.org; Thu, 06 Oct 2022 19:25:32 -0400
Received: from [10.253.37.70] (port=53682 helo=webmail.orcon.net.nz)
by smtp-1.orcon.net.nz with esmtpa (Exim 4.90_1)
(envelope-from <psainty@HIDDEN>)
id 1ogaF5-00051Y-Kx; Fri, 07 Oct 2022 12:25:28 +1300
Received: from ip-116-251-140-135.kinect.net.nz ([116.251.140.135])
via [10.253.37.253] by webmail.orcon.net.nz
with HTTP (HTTP/1.1 POST); Fri, 07 Oct 2022 12:25:27 +1300
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 07 Oct 2022 12:25:27 +1300
From: Phil Sainty <psainty@HIDDEN>
In-Reply-To: <87edvlxgeg.fsf@HIDDEN>
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
Message-ID: <7d2c3f76331b84c6580a27fd261c01a2@HIDDEN>
X-Sender: psainty@HIDDEN
User-Agent: Orcon Webmail
X-GeoIP: --
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
On 2022-10-07 01:53, Lars Ingebrigtsen wrote:
> Phil Sainty <psainty@HIDDEN> writes:
>> If the buffer did not already exist, *Messages* says:
>> File exists, but cannot be read
>
> I can reproduce this, too. I think it's likely that the delay is
> coming
> from the error message (which is a misleading error message). There's
> probably a "sleep-for 2" after displaying the error message?
>
> There's a bug report in debbugs somewhere about fixing the error
> message, but I can't find it now.
Perhaps https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42431 ?
There are also a handful of other hits at:
https://debbugs.gnu.org/cgi/search.cgi?phrase=%22File+exists%2C+but+cannot+be+read%22&search=search
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Oct 2022 02:48:02 +0000
Resent-Message-ID: <handler.58302.B58302.166511083122825 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166511083122825
(code B ref 58302); Fri, 07 Oct 2022 02:48:02 +0000
Received: (at 58302) by debbugs.gnu.org; 7 Oct 2022 02:47:11 +0000
Received: from localhost ([127.0.0.1]:33945 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1ogdOJ-0005w5-Gq
for submit <at> debbugs.gnu.org; Thu, 06 Oct 2022 22:47:11 -0400
Received: from smtp-2.orcon.net.nz ([60.234.4.43]:40271)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <psainty@HIDDEN>) id 1ogdOG-0005vw-UP
for 58302 <at> debbugs.gnu.org; Thu, 06 Oct 2022 22:47:10 -0400
Received: from [10.253.37.70] (port=33848 helo=webmail.orcon.net.nz)
by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1)
(envelope-from <psainty@HIDDEN>)
id 1ogdOE-00053z-Ub; Fri, 07 Oct 2022 15:47:07 +1300
Received: from ip-116-251-140-135.kinect.net.nz ([116.251.140.135])
via [10.253.37.253] by webmail.orcon.net.nz
with HTTP (HTTP/1.1 POST); Fri, 07 Oct 2022 15:47:06 +1300
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 07 Oct 2022 15:47:06 +1300
From: Phil Sainty <psainty@HIDDEN>
In-Reply-To: <87edvlxgeg.fsf@HIDDEN>
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
Message-ID: <18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
X-Sender: psainty@HIDDEN
User-Agent: Orcon Webmail
X-GeoIP: --
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2022-10-07 01:53, Lars Ingebrigtsen wrote:
> I can reproduce this, too. I think it's likely that the delay is
> coming
> from the error message (which is a misleading error message). There's
> probably a "sleep-for 2" after displaying the error message?
True, `after-find-file' does this:
(or not-serious (sit-for 1 t))
And indeed that accounts for 1s of the ~2.5s delay; so this is
a significant factor, yet seemingly not the only issue.
With that commented out I now get:
Elapsed time: 0.835925s (0.039518s in 1 GCs) ;; find-file-noselect-1
(1.7317769889999999 1 0.03951770099999996) ;; the overall
benchmark-run
Instead of the former:
Elapsed time: 1.876737s (0.057295s in 1 GCs) ;; find-file-noselect-1
(2.680159853 1 0.057295379000000146) ;; the overall
benchmark-run
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Oct 2022 11:49:02 +0000
Resent-Message-ID: <handler.58302.B58302.166514332713802 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Phil Sainty <psainty@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166514332713802
(code B ref 58302); Fri, 07 Oct 2022 11:49:02 +0000
Received: (at 58302) by debbugs.gnu.org; 7 Oct 2022 11:48:47 +0000
Received: from localhost ([127.0.0.1]:34561 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oglqR-0003aY-BQ
for submit <at> debbugs.gnu.org; Fri, 07 Oct 2022 07:48:47 -0400
Received: from quimby.gnus.org ([95.216.78.240]:51622)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <larsi@HIDDEN>) id 1oglqP-0003aL-MH
for 58302 <at> debbugs.gnu.org; Fri, 07 Oct 2022 07:48:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID
:Date:References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=b9fKRY0rb1N2uXRXH2SByc0DBhn8qmJB0A9Z2ibR5PU=; b=V6kkhV7hM9HdZSTAL2PlcHKXmR
l1yUcQ9Rh2JwyNAzcyJYCieMqH2/KCZ2j00K4g+e+dcTNCNoIBu9FrDjZQzhAC0ymPztEmEA7wcAy
44ovBbQk6IM1ouxO5v+I9abFPriw8b4fkhwL0S1M/RUhKVokgu94+JnFcvb/MQx3Aan4=;
Received: from [84.212.220.105] (helo=downe)
by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92) (envelope-from <larsi@HIDDEN>)
id 1oglqG-0004zU-C7; Fri, 07 Oct 2022 13:48:39 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <7d2c3f76331b84c6580a27fd261c01a2@HIDDEN> (Phil
Sainty's message of "Fri, 07 Oct 2022 12:25:27 +1300")
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
<7d2c3f76331b84c6580a27fd261c01a2@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAG1BMVEXp59n9/vOopZ7M
yMcmJCdlYl/Ev7uEgXv///9v3jXmAAAAAWJLR0QIht6VegAAAAd0SU1FB+YKBwssAO7K9mgAAAGf
SURBVDjLldNNT+wgFAZgOsRZdzTmbkcYmG0t2ru/gm6VcsatguLeq/Hvy9c0Y1tNPMkk9Dy8MPQD
VatcJNd5uVyh/UDmupuC+g6+S5ifAKT5RQIAVPidxXFXHUA4wysh9jEMT0OuHuCgjLypxQychq3o
HGykVG4G/oRAL2bAaKnEDBypkxiYAJZrFgNjwEJbuZtAjYXomCJuBHWcqY3mo0Tqd5Rb9xVwvBQX
j1g0+BByX7Rhete4AdIy7S6jaIZEnWerAgIXyH1i05FLBA3LtwTMv7LRA45Qtv3L0nMIZU2PHKpL
ugVztZHXsf8m+2aJvMtgpeTPShHCCAsrLpDPfc4glSas3JKY6MSiJ2Qb+lv4gF36Wwk22v0n5D4F
0q0NUxOAbLT9AGDA3f6MES4VVIYA4fumL9CCry5ADpPDQhnCe+mO34GKw4qgV6vFEqCfQHjDLTPg
RuC7dYOJgZ2fAPA2fABV68bwtjV9y9eIjvY40ffxuLQZLXWL7ZYjMS5kb6vFCxVTeL5b0ss5sOqJ
ejEDfHPTiTnwnu6f7pf6BFI0yyot5I1sAAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTEwLTA3VDEx
OjQ0OjAwKzAwOjAwQ/mHSgAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMi0xMC0wN1QxMTo0NDowMCsw
MDowMDKkP/YAAAAASUVORK5CYII=
X-Now-Playing: Yukihiro Takahashi's _Murdered by the Music_: "The Core of Eden"
Date: Fri, 07 Oct 2022 13:48:35 +0200
Message-ID: <871qrjx3ak.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: Phil Sainty <psainty@HIDDEN> writes: >> coming >> from
the error message (which is a misleading error message). There's >> probably
a "sleep-for 2" after displaying the error message? >> There's a bug report
in debbugs somewhere about fi [...]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Phil Sainty <psainty@HIDDEN> writes:
>> coming
>> from the error message (which is a misleading error message). There's
>> probably a "sleep-for 2" after displaying the error message?
>> There's a bug report in debbugs somewhere about fixing the error
>> message, but I can't find it now.
>
> Perhaps https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D42431 ?
Yes, that's the one I was thinking about, and it was apparently fixed at
the time? But this looks like pretty much the same problem, but with a
different code path...
Phil Sainty <psainty@HIDDEN> writes:
> True, `after-find-file' does this:
>
> (or not-serious (sit-for 1 t))
>
> And indeed that accounts for 1s of the ~2.5s delay; so this is
> a significant factor, yet seemingly not the only issue.
>
> With that commented out I now get:
>
> Elapsed time: 0.835925s (0.039518s in 1 GCs) ;; find-=E2=81=A0file-=E2=81=
=A0noselect-=E2=81=A01
> (1.7317769889999999 1 0.03951770099999996) ;; the overall
> benchmark-run
>
> Instead of the former:
>
> Elapsed time: 1.876737s (0.057295s in 1 GCs) ;; find-=E2=81=A0file-=E2=81=
=A0noselect-=E2=81=A01
> (2.680159853 1 0.057295379000000146) ;; the overall
> benchmark-run
Perhaps there's something else that also wants to sleep a bit after a
file error... In any case, I think the real fix is to not signal an
error here, because that's wrong.
I haven't looked at this code in a while, though.
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 12 Oct 2022 10:27:02 +0000
Resent-Message-ID: <handler.58302.B58302.166557037327559 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166557037327559
(code B ref 58302); Wed, 12 Oct 2022 10:27:02 +0000
Received: (at 58302) by debbugs.gnu.org; 12 Oct 2022 10:26:13 +0000
Received: from localhost ([127.0.0.1]:55803 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oiYwG-0007AR-Os
for submit <at> debbugs.gnu.org; Wed, 12 Oct 2022 06:26:13 -0400
Received: from smtp-2.orcon.net.nz ([60.234.4.43]:49101)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <psainty@HIDDEN>) id 1oiYwD-0007AG-Kt
for 58302 <at> debbugs.gnu.org; Wed, 12 Oct 2022 06:26:11 -0400
Received: from [10.253.37.70] (port=51093 helo=webmail.orcon.net.nz)
by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1)
(envelope-from <psainty@HIDDEN>)
id 1oiYvx-0000lH-K4; Wed, 12 Oct 2022 23:26:07 +1300
Received: from ip-116-251-140-135.kinect.net.nz ([116.251.140.135])
via [10.253.37.253] by webmail.orcon.net.nz
with HTTP (HTTP/1.1 POST); Wed, 12 Oct 2022 23:25:52 +1300
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 12 Oct 2022 23:25:52 +1300
From: Phil Sainty <psainty@HIDDEN>
In-Reply-To: <18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
<18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
Message-ID: <d3c5f2c00773da6c4148c4f29fe6a29e@HIDDEN>
X-Sender: psainty@HIDDEN
User-Agent: Orcon Webmail
X-GeoIP: --
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2022-10-07 15:47, Phil Sainty wrote:
> (or not-serious (sit-for 1 t))
With that commented out, I tried to do some profiling like this:
(progn
(profiler-start 'cpu)
(browse-url-emacs "http://www.example.com")
(profiler-report)
(profiler-stop)
(profiler-reset)
(kill-buffer "www.example.com"))
The results were perplexing in their variability -- all I can
suggest is that you run that code multiple times, and C-u RET
to expand the full profile after each run, and see whether you
also observe a variety of fairly different outcomes.
Here's one example where we can see `url-retrieve-synchronously'
being called 4 times; but other times it was called 2-3 times,
and the profile looked rather different.
23 69% - browse-url-emacs
23 69% - find-file-other-window
23 69% - find-file-noselect
17 51% - find-file-noselect-1
8 24% - after-find-file
8 24% - if
4 12% - let*
4 12% - cond
4 12% - and
4 12% - file-exists-p
4 12% - url-file-handler
4 12% - apply
4 12% - url-file-exists-p
4 12% - url-http-file-exists-p
4 12% - url-http-head
4 12% - url-retrieve-synchronously
4 12% - accept-process-output
4 12% - url-http-generic-filter
4 12% -
url-http-wait-for-headers-change-function
4 12% mail-fetch-field
4 12% - run-hooks
4 12% - vc-refresh-state
4 12% - vc-backend
4 12% - vc-file-getprop
4 12% - expand-file-name
4 12% url-file-handler
6 18% - insert-file-contents
6 18% - url-file-handler
6 18% - apply
6 18% - url-insert-file-contents
4 12% url-retrieve-synchronously
2 6% - url-insert-buffer-contents
2 6% - url-insert
2 6% - mm-dissect-buffer
2 6% - mm-dissect-singlepart
2 6% - mm-copy-to-buffer
2 6% generate-new-buffer
3 9% - file-readable-p
3 9% - url-file-handler
3 9% - apply
3 9% - url-file-exists-p
3 9% - url-http-file-exists-p
3 9% - url-http-head
3 9% - url-retrieve-synchronously
3 9% - url-retrieve
3 9% - url-retrieve-internal
3 9% url-http
6 18% - file-attributes
6 18% - url-file-handler
6 18% - apply
6 18% - url-file-attributes
6 18% - url-http-file-attributes
6 18% - url-http-head-file-attributes
6 18% - url-http-head
6 18% - url-retrieve-synchronously
6 18% - url-retrieve
6 18% - url-retrieve-internal
6 18% - url-http
6 18% generate-new-buffer
10 30% Automatic GC
I'm not very familiar with the ins and outs of these code paths,
but my first impression is that we've initiated an operation which
needs to deal with a particular URL and if we were to make a high-
level binding to indicate that we were doing this, we could then
cache and re-use the results of those network requests for the
extent of that binding.
3 of the 4 `url-retrieve-synchronously' calls above are from
`url-http-head'; twice on account of `url-file-exists-p', and another
from `url-file-attributes'.
I see the following in the code:
(defun url-http-head (url)
(let ((url-request-method "HEAD")
(url-request-data nil))
(url-retrieve-synchronously url)))
(defun url-http-file-exists-p (url)
(let ((buffer (url-http-head url)))
...))
(defalias 'url-http-file-readable-p 'url-http-file-exists-p)
(defun url-http-head-file-attributes (url &optional _id-format)
(let ((buffer (url-http-head url)))
...))
(defun url-http-file-attributes (url &optional id-format)
(if (url-dav-supported-p url)
(url-dav-file-attributes url id-format)
(url-http-head-file-attributes url id-format)))
In principle, I don't see why we couldn't be re-using the buffer
returned by the first call `url-http-head' in each of the
subsequent calls.
Furthermore, we could *probably* flag the fact that we are 100%
intending to request the entire file later on in the command,
and use that information to just do a GET request instead of a
HEAD request in the first place -- the resulting buffer for which
can then *also* be re-used by the eventual `url-insert-file-contents'
call.
I think `url-http-head' itself should only ever do a HEAD request,
but `url-http-head-file-attributes' and `url-http-file-exists-p'
could conditionally use the full GET buffer.
-Phil
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 12 Oct 2022 11:05:01 +0000
Resent-Message-ID: <handler.58302.B58302.166557265331363 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Phil Sainty <psainty@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166557265331363
(code B ref 58302); Wed, 12 Oct 2022 11:05:01 +0000
Received: (at 58302) by debbugs.gnu.org; 12 Oct 2022 11:04:13 +0000
Received: from localhost ([127.0.0.1]:55846 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oiZX3-00089l-18
for submit <at> debbugs.gnu.org; Wed, 12 Oct 2022 07:04:13 -0400
Received: from quimby.gnus.org ([95.216.78.240]:50108)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <larsi@HIDDEN>) id 1oiZX1-00089W-CE
for 58302 <at> debbugs.gnu.org; Wed, 12 Oct 2022 07:04:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=cgZc/al7UttM+fALAex0XlQjZ+7+vwsYF3Q6pttadzc=; b=blgmPwigAdcP4kW/xORZKVpfTX
hpNclW9dKKzyZBgBElLzGch7D0xz63DsXAFX9twnMIPWxyS/dZEC6AdPcDPizkymkGkaj9vMkb358
RpyWF6lUT6CG+eed73UuTNp2s1jxryZ/JEkknjnl+S0d/sNxQzvgwYVEpeMnl/RMmQmk=;
Received: from [84.212.220.105] (helo=downe)
by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92) (envelope-from <larsi@HIDDEN>)
id 1oiZWq-0005zg-KJ; Wed, 12 Oct 2022 13:04:02 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <d3c5f2c00773da6c4148c4f29fe6a29e@HIDDEN> (Phil
Sainty's message of "Wed, 12 Oct 2022 23:25:52 +1300")
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
<18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
<d3c5f2c00773da6c4148c4f29fe6a29e@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAHlBMVEW9p4bHsI3Vwobj
2Gv8+GrW0FvCu1a6s1LWxXj///9wtT3jAAAAAWJLR0QJ8dml7AAAAAd0SU1FB+YKDAo5O763FG4A
AAC3SURBVDjLxZThDcIgEIXv4gJ3jtAVOF0AOgElDmCkExRXcGxpNE3aHlrUxAe/+PLueAQAQFYF
jKQD5GbfPDQHOzfpa9AGI+I7Y1cgXuNwTH2UraWsOLHOyLpHOl9OIaZYsd1D58R1CrBDSr0a0IcQ
fnEkH4J2bK8B640vOLxs7cG3SXOQr8k4VgJgXS8A1jqwGpSfgS4CxgKoDzivRG8dVM7BfwNU75jy
ETzzUv518vIIEChPWOgOlM94FReCeJ8AAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMTAtMTJUMTA6
NTc6NTkrMDA6MDCUUWfuAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTEwLTEyVDEwOjU3OjU5KzAw
OjAw5QzfUgAAAABJRU5ErkJggg==
X-Now-Playing: Nobukazu Takemura's _Music for the exhibition "Einheit"_:
"(untitled)"
Date: Wed, 12 Oct 2022 13:03:59 +0200
Message-ID: <8735bte21s.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: Phil Sainty <psainty@HIDDEN> writes: > I'm not very
familiar with the ins and outs of these code paths, > but my first impression
is that we've initiated an operation which > needs to deal with a particular
URL and if we were to make a h [...]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Phil Sainty <psainty@HIDDEN> writes:
> I'm not very familiar with the ins and outs of these code paths,
> but my first impression is that we've initiated an operation which
> needs to deal with a particular URL and if we were to make a high-
> level binding to indicate that we were doing this, we could then
> cache and re-use the results of those network requests for the
> extent of that binding.
[excellent analysis elided]
I think the conclusion here is that using the file-name-handler-alist
stuff for this is the absolutely pessimal way to implement
`browse-url-emacs'.
It should be pretty easy to rewrite browse-url-emacs to just call
`url-retrieve-synchronously' explicitly, and then display the resulting
data -- and it should be much, much faster.
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Phil Sainty <psainty@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 12 Oct 2022 11:29:02 +0000
Resent-Message-ID: <handler.58302.B58302.16655741051340 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Lars Ingebrigtsen <larsi@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.16655741051340
(code B ref 58302); Wed, 12 Oct 2022 11:29:02 +0000
Received: (at 58302) by debbugs.gnu.org; 12 Oct 2022 11:28:25 +0000
Received: from localhost ([127.0.0.1]:55914 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oiZuT-0000LX-Fx
for submit <at> debbugs.gnu.org; Wed, 12 Oct 2022 07:28:25 -0400
Received: from smtp-2.orcon.net.nz ([60.234.4.43]:52293)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <psainty@HIDDEN>) id 1oiZuQ-0000LO-Gi
for 58302 <at> debbugs.gnu.org; Wed, 12 Oct 2022 07:28:24 -0400
Received: from [10.253.37.70] (port=42048 helo=webmail.orcon.net.nz)
by smtp-2.orcon.net.nz with esmtpa (Exim 4.90_1)
(envelope-from <psainty@HIDDEN>)
id 1oiZuO-0005oj-GI; Thu, 13 Oct 2022 00:28:20 +1300
Received: from ip-116-251-140-135.kinect.net.nz ([116.251.140.135])
via [10.253.37.253] by webmail.orcon.net.nz
with HTTP (HTTP/1.1 POST); Thu, 13 Oct 2022 00:28:20 +1300
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 13 Oct 2022 00:28:20 +1300
From: Phil Sainty <psainty@HIDDEN>
In-Reply-To: <8735bte21s.fsf@HIDDEN>
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
<18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
<d3c5f2c00773da6c4148c4f29fe6a29e@HIDDEN>
<8735bte21s.fsf@HIDDEN>
Message-ID: <62e7deefa46f031798e6bf6ea927e7dc@HIDDEN>
X-Sender: psainty@HIDDEN
User-Agent: Orcon Webmail
X-GeoIP: --
X-Spam_score: -2.9
X-Spam_score_int: -28
X-Spam_bar: --
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 2022-10-13 00:03, Lars Ingebrigtsen wrote:
> I think the conclusion here is that using the file-name-handler-alist
> stuff for this is the absolutely pessimal way to implement
> `browse-url-emacs'.
>
> It should be pretty easy to rewrite browse-url-emacs to just call
> `url-retrieve-synchronously' explicitly, and then display the resulting
> data -- and it should be much, much faster.
Undoubtedly so; but making the existing approach more efficient might
also bring the same benefits to other functionality?
E.g.:
(url-handler-mode 1)
(trace-function 'url-retrieve-synchronously "*trace-output*"
(lambda () (format " [%s]" url-request-method)))
(find-file "http://www.example.com")
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t t)) [OPTIONS]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[OPTIONS]
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t nil)) [HEAD]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[HEAD]
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t t)) [OPTIONS]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[OPTIONS]
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t nil)) [HEAD]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[HEAD]
======================================================================
1 -> (url-retrieve-synchronously "http://www.example.com") [nil]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[nil]
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t t)) [HEAD]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[HEAD]
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t t)) [HEAD]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[HEAD]
======================================================================
1 -> (url-retrieve-synchronously #s(url "http" nil nil "www.example.com"
nil "" nil nil t nil t t)) [HEAD]
1 <- url-retrieve-synchronously: #<buffer *http www.example.com:80*>
[HEAD]
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 12 Oct 2022 11:34:02 +0000
Resent-Message-ID: <handler.58302.B58302.166557443810358 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Phil Sainty <psainty@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166557443810358
(code B ref 58302); Wed, 12 Oct 2022 11:34:02 +0000
Received: (at 58302) by debbugs.gnu.org; 12 Oct 2022 11:33:58 +0000
Received: from localhost ([127.0.0.1]:55928 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oiZzp-0002h0-Rs
for submit <at> debbugs.gnu.org; Wed, 12 Oct 2022 07:33:58 -0400
Received: from quimby.gnus.org ([95.216.78.240]:50636)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <larsi@HIDDEN>) id 1oiZzo-0002gn-24
for 58302 <at> debbugs.gnu.org; Wed, 12 Oct 2022 07:33:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=8pKKG15a7c4GQNP+62WFwpV20E3FjpAeTuduFByKB34=; b=W73jP/9cdn17VN2te+pRxWaFAY
IF45pkHxrdSqYH8RZZCNCk4aFmgDlRxeO7mVaSSUFn0CAKbQtkGEX6RXC4S1M/VWlyHZETB3yGFd8
dmT85AIQsTehfBcxWaZwhLDFmz1NfWDpwQPKp55sUPBymj6XD9nTf8X7KJZP/a4B3o3I=;
Received: from [84.212.220.105] (helo=downe)
by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92) (envelope-from <larsi@HIDDEN>)
id 1oiZzf-0006DX-Bu; Wed, 12 Oct 2022 13:33:49 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <62e7deefa46f031798e6bf6ea927e7dc@HIDDEN> (Phil
Sainty's message of "Thu, 13 Oct 2022 00:28:20 +1300")
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
<18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
<d3c5f2c00773da6c4148c4f29fe6a29e@HIDDEN>
<8735bte21s.fsf@HIDDEN>
<62e7deefa46f031798e6bf6ea927e7dc@HIDDEN>
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj
SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAHlBMVEW9p4bHsI3Vwobj
2Gv8+GrW0FvCu1a6s1LWxXj///9wtT3jAAAAAWJLR0QJ8dml7AAAAAd0SU1FB+YKDAo5O763FG4A
AAC3SURBVDjLxZThDcIgEIXv4gJ3jtAVOF0AOgElDmCkExRXcGxpNE3aHlrUxAe/+PLueAQAQFYF
jKQD5GbfPDQHOzfpa9AGI+I7Y1cgXuNwTH2UraWsOLHOyLpHOl9OIaZYsd1D58R1CrBDSr0a0IcQ
fnEkH4J2bK8B640vOLxs7cG3SXOQr8k4VgJgXS8A1jqwGpSfgS4CxgKoDzivRG8dVM7BfwNU75jy
ETzzUv518vIIEChPWOgOlM94FReCeJ8AAAAldEVYdGRhdGU6Y3JlYXRlADIwMjItMTAtMTJUMTA6
NTc6NTkrMDA6MDCUUWfuAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIyLTEwLTEyVDEwOjU3OjU5KzAw
OjAw5QzfUgAAAABJRU5ErkJggg==
X-Now-Playing: Nobukazu Takemura's _Music for the exhibition "Einheit"_:
"(untitled)"
Date: Wed, 12 Oct 2022 13:33:46 +0200
Message-ID: <87y1tlb7j9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: Phil Sainty <psainty@HIDDEN> writes: > Undoubtedly so;
but making the existing approach more efficient might > also bring the same
benefits to other functionality? > > E.g.: > > (url-handler-mode 1) > >
(trace-function 'url-retrieve-sync [...]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Phil Sainty <psainty@HIDDEN> writes:
> Undoubtedly so; but making the existing approach more efficient might
> also bring the same benefits to other functionality?
>
> E.g.:
>
> (url-handler-mode 1)
>
> (trace-function 'url-retrieve-synchronously "*trace-output*"
> (lambda () (format " [%s]" url-request-method)))
>
> (find-file "http://www.example.com")
That's true, but I kinda feel that this stuff is something that nobody
uses -- it's a fun trick, but you can't do much with it. That is, you
can load "http://www.example.com" as a file, but you can't save it, so...
It's a fun toy and a demonstration of how you can hook into the Emacs
file machinery. But if you're writing code that's actually going to be
used (like browse-url-emacs), it's the worst way.
X-Loop: help-debbugs@HIDDEN
Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?)
Resent-From: Lars Ingebrigtsen <larsi@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Oct 2022 08:02:01 +0000
Resent-Message-ID: <handler.58302.B58302.166564811323541 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 58302
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Phil Sainty <psainty@HIDDEN>
Cc: 58302 <at> debbugs.gnu.org
Received: via spool by 58302-submit <at> debbugs.gnu.org id=B58302.166564811323541
(code B ref 58302); Thu, 13 Oct 2022 08:02:01 +0000
Received: (at 58302) by debbugs.gnu.org; 13 Oct 2022 08:01:53 +0000
Received: from localhost ([127.0.0.1]:59349 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1oitA9-00067d-HD
for submit <at> debbugs.gnu.org; Thu, 13 Oct 2022 04:01:53 -0400
Received: from quimby.gnus.org ([95.216.78.240]:60254)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <larsi@HIDDEN>) id 1oitA7-00067P-BG
for 58302 <at> debbugs.gnu.org; Thu, 13 Oct 2022 04:01:51 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org;
s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References:
In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:
Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=PwU5myfdjXG8tBfcqtrhXCz26rjiv986x/BhtAiEmQ0=; b=m8kXrHnVPbJ7eyWH47vHmx33Kc
8N2BeKwk4RxzvKy933n2wver25ApsyvjQp2aUk81lIQP93zuEubxh9T/n7cRgK9zEwr9rY5GZ7z3f
X4B3pwx3uwzgp/FvHqoQtV7A0iCaqoD4nBW1UAXAAOQiO6qhEUXGrM5qvA/oxqJCIFv8=;
Received: from [84.212.220.105] (helo=downe)
by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92) (envelope-from <larsi@HIDDEN>)
id 1oit9y-0005uK-6X; Thu, 13 Oct 2022 10:01:44 +0200
From: Lars Ingebrigtsen <larsi@HIDDEN>
In-Reply-To: <87y1tlb7j9.fsf@HIDDEN> (Lars Ingebrigtsen's message of "Wed,
12 Oct 2022 13:33:46 +0200")
References: <929023db7615cc93faad294e3860ba5f@HIDDEN>
<87edvlxgeg.fsf@HIDDEN>
<18018e9dddf6e6d5d07a567a36b59a65@HIDDEN>
<d3c5f2c00773da6c4148c4f29fe6a29e@HIDDEN>
<8735bte21s.fsf@HIDDEN>
<62e7deefa46f031798e6bf6ea927e7dc@HIDDEN>
<87y1tlb7j9.fsf@HIDDEN>
X-Now-Playing: MX-80 Sound's _Subterranean Modern_: "Lady In Pain"
Date: Thu, 13 Oct 2022 10:01:41 +0200
Message-ID: <87lepk884a.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
@@CONTACT_ADDRESS@@ for details.
Content preview: I've now fixed the spurious error message in the middle of
this, so it should be faster now. It's still inefficient, but I'm not sure
that it's worth fixing...
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
I've now fixed the spurious error message in the middle of this, so it
should be faster now.
It's still inefficient, but I'm not sure that it's worth fixing...
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.