From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#58302: 29.0.50; browse-url-emacs is extremely slow (and I think always has been?) Date: Wed, 12 Oct 2022 23:25:52 +1300 Message-ID: References: <929023db7615cc93faad294e3860ba5f@webmail.orcon.net.nz> <87edvlxgeg.fsf@gnus.org> <18018e9dddf6e6d5d07a567a36b59a65@webmail.orcon.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14379"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Orcon Webmail Cc: 58302@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 12 12:27:13 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1oiYxF-0003Z3-D8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Oct 2022 12:27:13 +0200 Original-Received: from localhost ([::1]:46288 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oiYxD-00032p-PP for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 12 Oct 2022 06:27:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oiYx4-000326-Nd for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2022 06:27:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56726) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oiYx4-0004xd-FI for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2022 06:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oiYx4-0007BV-70 for bug-gnu-emacs@gnu.org; Wed, 12 Oct 2022 06:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 12 Oct 2022 10:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58302 X-GNU-PR-Package: emacs Original-Received: via spool by 58302-submit@debbugs.gnu.org id=B58302.166557037327559 (code B ref 58302); Wed, 12 Oct 2022 10:27:02 +0000 Original-Received: (at 58302) by debbugs.gnu.org; 12 Oct 2022 10:26:13 +0000 Original-Received: from localhost ([127.0.0.1]:55803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oiYwG-0007AR-Os for submit@debbugs.gnu.org; Wed, 12 Oct 2022 06:26:13 -0400 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:49101) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oiYwD-0007AG-Kt for 58302@debbugs.gnu.org; Wed, 12 Oct 2022 06:26:11 -0400 Original-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 ) id 1oiYvx-0000lH-K4; Wed, 12 Oct 2022 23:26:07 +1300 Original-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 In-Reply-To: <18018e9dddf6e6d5d07a567a36b59a65@webmail.orcon.net.nz> X-Sender: psainty@orcon.net.nz X-GeoIP: -- X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245182 Archived-At: 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