all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Make emacs-eww render asynchronously
@ 2019-03-19  4:48 YUE Daian
  2019-03-19 15:11 ` Óscar Fuentes
                   ` (5 more replies)
  0 siblings, 6 replies; 11+ messages in thread
From: YUE Daian @ 2019-03-19  4:48 UTC (permalink / raw)
  To: help-gnu-emacs

Hi folks,

I am facing a funny problem about Emacs browsers.

The story is: I was using emacs-w3m to browse Rust API docs.

You know some pages are very large, like this one:
https://doc.rust-lang.org/std/vec/struct.Vec.html

The emacs-w3m fetches the page asynchronously, but the rendering process
will freeze Emacs for a long time.

The eww opens it rather fast, but its functionality is not so good
compared with emacs-w3m.

Is it a way to make emacs-w3m render pages asynchronously?

Or should I start to use eww exclusively instead of emacs-w3m?

Thanks in advance!



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19  4:48 Make emacs-eww render asynchronously YUE Daian
@ 2019-03-19 15:11 ` Óscar Fuentes
  2019-03-19 18:10 ` Vladimir Sedach
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 11+ messages in thread
From: Óscar Fuentes @ 2019-03-19 15:11 UTC (permalink / raw)
  To: help-gnu-emacs

YUE Daian <sheepduke@gmail.com> writes:

> Hi folks,
>
> I am facing a funny problem about Emacs browsers.
>
> The story is: I was using emacs-w3m to browse Rust API docs.
>
> You know some pages are very large, like this one:
> https://doc.rust-lang.org/std/vec/struct.Vec.html
>
> The emacs-w3m fetches the page asynchronously, but the rendering process
> will freeze Emacs for a long time.

It is practically instantaneous here. The only observable delay (less
than a second) is for fetching the data.

> The eww opens it rather fast, but its functionality is not so good
> compared with emacs-w3m.
>
> Is it a way to make emacs-w3m render pages asynchronously?

I don't think so.

> Or should I start to use eww exclusively instead of emacs-w3m?

Use whatever works for you.

I suggest an experiment: create a local copy of that web page on your
computer and visit it with eww (something like M-x eww [enter]
file:///path/to/the/html/file). See if takes too long. Repeat it running
Emacs with "emacs -Q" and see if the delay goes away.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19  4:48 Make emacs-eww render asynchronously YUE Daian
  2019-03-19 15:11 ` Óscar Fuentes
@ 2019-03-19 18:10 ` Vladimir Sedach
  2019-03-19 19:13   ` Stefan Monnier
  2019-03-19 19:26   ` Óscar Fuentes
  2019-03-19 19:04 ` Stefan Monnier
                   ` (3 subsequent siblings)
  5 siblings, 2 replies; 11+ messages in thread
From: Vladimir Sedach @ 2019-03-19 18:10 UTC (permalink / raw)
  To: YUE Daian; +Cc: help-gnu-emacs

> The emacs-w3m fetches the page asynchronously, but the rendering process
> will freeze Emacs for a long time.

Yes, this is an actual problem. Óscar Fuentes probably does not
notice it because he must have a fast computer - if you are hacking
elisp code it is a good idea to do it on old slow hardware. I find
that profiler.el is not very useful for discovering things that cause
lag and latency. In case anyone is reading this and thinking "get off
your heirloom VAX grandpa, here is a nickel, buy a better computer,"
there is no reason for computers with gigahertz-plus CPUs and a
gigabyte of memory to end up in the landfill, even if they are 10+
years old. And work on performance issues caused by sloppy code and
bad algorithms/data structures will benefit all GNU Emacs users.

> Is it a way to make emacs-w3m render pages asynchronously?

The cause of the problem will not be fixed by asynchronous rendering.
emacs-w3m code has some real problems and is doing a lot of
unnecessary work.

If you would like to contribute to emacs-w3m, the details for
subscribing to the emacs-w3m mailing list can be found at:
http://emacs-w3m.namazu.org/

The source code repository is now at:
https://github.com/emacs-w3m/emacs-w3m

> Or should I start to use eww exclusively instead of emacs-w3m?

You can do both. It is probably easier to add features and w3m-style
rendering to eww than to fix emacs-w3m.

Vladimir



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19  4:48 Make emacs-eww render asynchronously YUE Daian
  2019-03-19 15:11 ` Óscar Fuentes
  2019-03-19 18:10 ` Vladimir Sedach
@ 2019-03-19 19:04 ` Stefan Monnier
  2019-03-19 19:31 ` Óscar Fuentes
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2019-03-19 19:04 UTC (permalink / raw)
  To: help-gnu-emacs

> Is it a way to make emacs-w3m render pages asynchronously?
> Or should I start to use eww exclusively instead of emacs-w3m?

I think "in theory" emacs-w3m should be faster than eww at rendering.
So if eww is faster it's either because of a problem in emacs-w3m that
can be fixed, or it's because eww does a much less thorough job.


        Stefan




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19 18:10 ` Vladimir Sedach
@ 2019-03-19 19:13   ` Stefan Monnier
  2019-03-19 19:26   ` Óscar Fuentes
  1 sibling, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2019-03-19 19:13 UTC (permalink / raw)
  To: help-gnu-emacs

> In case anyone is reading this and thinking "get off your heirloom VAX
> grandpa, here is a nickel, buy a better computer," there is no reason
> for computers with gigahertz-plus CPUs and a gigabyte of memory to end
> up in the landfill, even if they are 10+ years old.  And work on
> performance issues caused by sloppy code and bad algorithms/data
> structures will benefit all GNU Emacs users.

My main laptop is a Thinkpad T61, my office desktop is a 2006 mac-mini,
so yes, I fully agree.

>> The emacs-w3m fetches the page asynchronously, but the rendering process
>> will freeze Emacs for a long time.
> Yes, this is an actual problem.  Óscar Fuentes probably does not
> notice it because he must have a fast computer - if you are hacking
> elisp code it is a good idea to do it on old slow hardware.

One of the reasons why we can still use 10+ year old computers is
because even the fanciest newest CPUs aren't *that* much faster (on
single-threaded code, as is the case here) thanks to the end of Dennard
scaling, so if it's "less than a second" on Óscar's computer there's
a good chance that it should be much less than "a long time" on the
OP's machine.

IOW there's probably some other difference than the hardware at play here.


        Stefan




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19 18:10 ` Vladimir Sedach
  2019-03-19 19:13   ` Stefan Monnier
@ 2019-03-19 19:26   ` Óscar Fuentes
  1 sibling, 0 replies; 11+ messages in thread
From: Óscar Fuentes @ 2019-03-19 19:26 UTC (permalink / raw)
  To: help-gnu-emacs

Vladimir Sedach <vas@oneofus.la> writes:

>> The emacs-w3m fetches the page asynchronously, but the rendering process
>> will freeze Emacs for a long time.
>
> Yes, this is an actual problem. Óscar Fuentes probably does not
> notice it because he must have a fast computer

I reported that rendering was apparently instantaneous on my machine
(which, admitedly, is a fast one). But the OP says "the rendering
process will freeze Emacs for a long time". Even if his computer is 5%
of the speed of mine (such as a 15 years old mid-range desktop), it
would not cause a delay that fits that description.

Hence I suspect a problem with the OP's configuration.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19  4:48 Make emacs-eww render asynchronously YUE Daian
                   ` (2 preceding siblings ...)
  2019-03-19 19:04 ` Stefan Monnier
@ 2019-03-19 19:31 ` Óscar Fuentes
       [not found] ` <87zhpqn3af.fsf@exinda.orion.oneofus.la.>
       [not found] ` <5c9132a1.1c69fb81.b855.49c7SMTPIN_ADDED_BROKEN@mx.google.com>
  5 siblings, 0 replies; 11+ messages in thread
From: Óscar Fuentes @ 2019-03-19 19:31 UTC (permalink / raw)
  To: help-gnu-emacs

YUE Daian <sheepduke@gmail.com> writes:

> The emacs-w3m fetches the page asynchronously, but the rendering process
> will freeze Emacs for a long time.
>
> The eww opens it rather fast, but its functionality is not so good
> compared with emacs-w3m.

I misread the message and got the impression that eww was the slow one
here. My test was with eww. I don't have emacs-w3m around.

My apologies.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
       [not found] ` <87zhpqn3af.fsf@exinda.orion.oneofus.la.>
@ 2019-03-19 19:35   ` Eli Zaretskii
  2019-03-20  7:03     ` Vladimir Sedach
  0 siblings, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2019-03-19 19:35 UTC (permalink / raw)
  To: help-gnu-emacs

> From: Vladimir Sedach <vas@oneofus.la>
> Date: Tue, 19 Mar 2019 11:10:32 -0700
> Cc: help-gnu-emacs@gnu.org
> 
> I find that profiler.el is not very useful for discovering things
> that cause lag and latency.

I can only understand that claim if in your case the slowdown/lagging
is due to redisplay, which is written almost entirely in C, and
profiler.el sees it as just one function.  Otherwise, profiler.el is
generally a very useful tool for spotting hot spots and bottlenecks,
IME.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
       [not found] ` <5c9132a1.1c69fb81.b855.49c7SMTPIN_ADDED_BROKEN@mx.google.com>
@ 2019-03-20  4:31   ` YUE Daian
  0 siblings, 0 replies; 11+ messages in thread
From: YUE Daian @ 2019-03-20  4:31 UTC (permalink / raw)
  To: help-gnu-emacs

On 2019-03-19 11:10, Vladimir Sedach <vas@oneofus.la> wrote:
>> The emacs-w3m fetches the page asynchronously, but the rendering process
>> will freeze Emacs for a long time.
>
> Yes, this is an actual problem. Óscar Fuentes probably does not
> notice it because he must have a fast computer - if you are hacking
> elisp code it is a good idea to do it on old slow hardware. I find
> that profiler.el is not very useful for discovering things that cause
> lag and latency. In case anyone is reading this and thinking "get off
> your heirloom VAX grandpa, here is a nickel, buy a better computer,"
> there is no reason for computers with gigahertz-plus CPUs and a
> gigabyte of memory to end up in the landfill, even if they are 10+
> years old. And work on performance issues caused by sloppy code and
> bad algorithms/data structures will benefit all GNU Emacs users.
>

>> Is it a way to make emacs-w3m render pages asynchronously?
>
> The cause of the problem will not be fixed by asynchronous rendering.
> emacs-w3m code has some real problems and is doing a lot of
> unnecessary work.
>
> If you would like to contribute to emacs-w3m, the details for
> subscribing to the emacs-w3m mailing list can be found at:
> http://emacs-w3m.namazu.org/
>
> The source code repository is now at:
> https://github.com/emacs-w3m/emacs-w3m
>
>> Or should I start to use eww exclusively instead of emacs-w3m?
>
> You can do both. It is probably easier to add features and w3m-style
> rendering to eww than to fix emacs-w3m.
>
> Vladimir

Maybe you are right. IMHO emacs-w3m is not easy to hack.

Then the question would become "how to make eww fetch pages
asynchronously." ;-)



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-19 19:35   ` Eli Zaretskii
@ 2019-03-20  7:03     ` Vladimir Sedach
  2019-03-20 14:04       ` Stefan Monnier
  0 siblings, 1 reply; 11+ messages in thread
From: Vladimir Sedach @ 2019-03-20  7:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: help-gnu-emacs

> I can only understand that claim if in your case the slowdown/lagging
> is due to redisplay, which is written almost entirely in C, and
> profiler.el sees it as just one function.

Yes, that is the case. Another case is external processes (which
applies for emacs-w3m).

Profiler-Report gives a ratio of CPU usage by Emacs code but not
timing information. benchmark.el is useful, but you need to figure
out what to benchmark first, which is not always obvious.

Vladimir



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Make emacs-eww render asynchronously
  2019-03-20  7:03     ` Vladimir Sedach
@ 2019-03-20 14:04       ` Stefan Monnier
  0 siblings, 0 replies; 11+ messages in thread
From: Stefan Monnier @ 2019-03-20 14:04 UTC (permalink / raw)
  To: help-gnu-emacs

> Profiler-Report gives a ratio of CPU usage by Emacs code but not
> timing information. benchmark.el is useful, but you need to figure
> out what to benchmark first, which is not always obvious.

There's also `elp`, which is often a lot more convenient to use than
benchmark in those cases.  It also suffers from the problem that you
need to figure out what to instrument, but you can more easily
instrument "everything within reach",


        Stefan




^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-03-20 14:04 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-03-19  4:48 Make emacs-eww render asynchronously YUE Daian
2019-03-19 15:11 ` Óscar Fuentes
2019-03-19 18:10 ` Vladimir Sedach
2019-03-19 19:13   ` Stefan Monnier
2019-03-19 19:26   ` Óscar Fuentes
2019-03-19 19:04 ` Stefan Monnier
2019-03-19 19:31 ` Óscar Fuentes
     [not found] ` <87zhpqn3af.fsf@exinda.orion.oneofus.la.>
2019-03-19 19:35   ` Eli Zaretskii
2019-03-20  7:03     ` Vladimir Sedach
2019-03-20 14:04       ` Stefan Monnier
     [not found] ` <5c9132a1.1c69fb81.b855.49c7SMTPIN_ADDED_BROKEN@mx.google.com>
2019-03-20  4:31   ` YUE Daian

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.