[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
   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