[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
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
(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"))
(message "debug: 2: %s" (format-time-string "%M:%S"))
(message "debug: 3: %s" (format-time-string "%M:%S"))
(message "debug: 4: %s" (format-time-string "%M:%S"))
(message "debug: 5: %s" (format-time-string "%M:%S"))
(unless (eq w3m-type 'w3m-m17n)
(message "debug: 6: %s" (format-time-string "%M:%S"))
(message "debug: 7: %s" (format-time-string "%M:%S"))
(message "debug: 8: %s" (format-time-string "%M:%S"))
(message "debug: 9: %s" (format-time-string "%M:%S"))
(w3m--message t t "Rendering...done")
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
I'd appreciate any possible further help with this.
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0