[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: link or page not rendered
On 2019-07-01 08:30, Katsumi Yamaoka wrote:
> In [emacs-w3m:13478]
> On Sat, 29 Jun 2019 04:56:20 +0000, Andrés Ramírez wrote:
> > This page loads from command line. But not from within emacs-w3m
> > http://www.cs.yale.edu/homes/aspnes/classes/223/notes.html
>
> Confirmed. I tried downloading notes.html, visited it in an Emacs
> buffer, and run M-x w3m-buffer . It worked but fontifying took
> very very long time. The `M-x w3m RET url_in_question RET' is
> also the case probably. So far I don't know how to make it fast.
> Unfortunately it might be the limit of emacs-w3m.
Some notes. Hope they can be helpful in continuing with this.
1] I had much better responsiveness using w3m directly:
$ w3m http://www.cs.yale.edu/homes/aspnes/classes/223/notes.html
2] Using the emacs profiler didn't give me any surprising feedback.
3] More useful was observing htop and the emacs mini-buffer during
processing. For the first half of the procedure time-wise, it seems
emacs doesn't even receive the raw html. The emacs process during
that period is mostly using 0-20% cpu%, so there may be a
bottleneck between emacs-w3m and w3m, or emacs-w3m isn't getting the
message that w3m has completed and that its time to start rendering.
Once emacs-w3m does start rendering, only then does htop show emacs
gobbling up cpu resources ~100% for the entire second half.
4] In order to focus on the 'second' half of the problem, the rendering
problem, I saved the html locally, and performed the following when
loading the local copy.
5] Here's some 'manual' profiling, and what I'm coming up with is
that almost the entire rendering delay is due to function
w3m-fix-illegal-blocks.
6] Try evaluating the following, then load a local copy of the html
file. When it completes, view the messages buffer to see the time
stamps.
#+BEGIN_SRC emacs-lisp
(defun w3m-rendering-buffer (&optional charset)
"Do rendering of contents in the currenr buffer as HTML and return title."
(w3m--message nil t "Rendering...")
(message "debug: 1: %s" (format-time-string "%M:%S"))
(w3m-remove-comments)
(message "debug: 2: %s" (format-time-string "%M:%S"))
(w3m-remove-invisible-image-alt)
(message "debug: 3: %s" (format-time-string "%M:%S"))
(w3m-check-header-tags)
(message "debug: 4: %s" (format-time-string "%M:%S"))
(w3m-check-refresh-attribute)
(message "debug: 5: %s" (format-time-string "%M:%S"))
(unless (eq w3m-type 'w3m-m17n)
(w3m-remove-meta-charset-tags))
(message "debug: 6: %s" (format-time-string "%M:%S"))
(w3m-fix-illegal-blocks)
(message "debug: 7: %s" (format-time-string "%M:%S"))
(w3m-markup-urls-nobreak)
(message "debug: 8: %s" (format-time-string "%M:%S"))
(w3m-rendering-half-dump charset)
(message "debug: 9: %s" (format-time-string "%M:%S"))
(w3m--message t t "Rendering...done")
(w3m-rendering-extract-title))
#+END_SRC
7] Now comment out the line (w3m-fix-illegal-blocks), re-evaluate the
snippet, and tell me what is deficient in the result. It looks to me
that page is rendered fine. What am I missing? Anything? I'm sure
that the function was put there for a good reason, but this page at
least seems fine without it, and it saves me ~40 seconds for the
local page load!
8] Continuing in the same manual manner with the fontifying part of the
rendering, its function w3m-fontify-anchors that's taking almost the
entire fontifying time, for me ~20 seconds. I don't see anything
obvious there to target, but I'm getting tired, so I'd like to stop
now.
I'd appreciate any possible further help with this.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0