[Date Prev][Date Next][Thread Prev][][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

#+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"))
  (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"))
  (w3m-rendering-half-dump charset)
  (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