emacs 23 display slow over cable modem

emacs 23 display slow over cable modem

[Strozzi, David J.]

Hi,

I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
work.  I connect over VPN from home, where I have a cable modem.  For a long
time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
terminal) has performed fine - after it starts (which may take some time),
typing, switching buffers, etc is pretty instant.  But, doing the same thing
in 23.2 gives much slower response.  Both work fine in -nw mode, but there
are some reasons (keyboard mappings, multi-windows, mouse) why I like the
full xwin app.  From my office, both xwin's run very fast.

Any ideas on why?  I just do text, no image stuff in emacs.  I'd really like
to use emacs 23, remotely, the full xwin app, and have the speed be like
emacs 21.

Thanks,
David Strozzi

Re: emacs 23 display slow over cable modem

[Daniel Pittman]

"Strozzi, David J." <strozzi2@llnl.gov> writes:

> I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
> work.  I connect over VPN from home, where I have a cable modem.  For a long
> time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
> terminal) has performed fine - after it starts (which may take some time),
> typing, switching buffers, etc is pretty instant.  But, doing the same thing
> in 23.2 gives much slower response.  Both work fine in -nw mode, but there
> are some reasons (keyboard mappings, multi-windows, mouse) why I like the
> full xwin app.  From my office, both xwin's run very fast.
>
> Any ideas on why?

At a guess, because Emacs 23 uses Xft for font rendering, which provides nice
anti-aliased display, while Emacs 21 uses only X core fonts.

Theoretically the X server caching and client libraries make Xft reasonably
efficient over long, thin pipes, but practically it is optimized on the
assumption that people basically don't do this any more.

If you can live without the better fonts you can still turn on the core font
backend after install[1] and just use that.

Regards,
        Daniel

Footnotes: 
[1]  Read the manual, I don't actually know how, I fear. :)

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

Re: emacs 23 display slow over cable modem

[Eli Zaretskii]

> From: Daniel Pittman <daniel@rimspace.net>
> Date: Sun, 24 Oct 2010 23:27:25 +1100
> 
> If you can live without the better fonts you can still turn on the core font
> backend after install[1] and just use that.
> 
> Footnotes: 
> [1]  Read the manual, I don't actually know how, I fear. :)

From the NEWS:

   *** Which font backends to use can be specified by the X resource
   "FontBackend".  For instance, to use both X core fonts and Xft fonts:

   Emacs.FontBackend: x,xft

   If this resource is not set, Emacs tries to use all font backends
   available on your graphic device.

   *** New frame parameter `font-backend' specifies a list of
   font-backends supported by the frame's graphic device.  On X, they are
   currently `x' and `xft'.

Re: emacs 23 display slow over cable modem

[despen]

"Strozzi, David J." <strozzi2@llnl.gov> writes:

> Hi,
>
> I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
> work.  I connect over VPN from home, where I have a cable modem.  For a long
> time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
> terminal) has performed fine - after it starts (which may take some time),
> typing, switching buffers, etc is pretty instant.  But, doing the same thing
> in 23.2 gives much slower response.  Both work fine in -nw mode, but there
> are some reasons (keyboard mappings, multi-windows, mouse) why I like the
> full xwin app.  From my office, both xwin's run very fast.
>
> Any ideas on why?  I just do text, no image stuff in emacs.  I'd really like
> to use emacs 23, remotely, the full xwin app, and have the speed be like
> emacs 21.

See this thread and see if it applies to your case:

http://groups.google.com/group/gnu.emacs.help/browse_thread/thread/bd7e102326bec6b2

Re: emacs 23 display slow over cable modem

[Stefan Monnier]

>> I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
>> work.  I connect over VPN from home, where I have a cable modem.  For a long
>> time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
>> terminal) has performed fine - after it starts (which may take some time),
>> typing, switching buffers, etc is pretty instant.  But, doing the same thing
>> in 23.2 gives much slower response.  Both work fine in -nw mode, but there
>> are some reasons (keyboard mappings, multi-windows, mouse) why I like the
>> full xwin app.  From my office, both xwin's run very fast.

Sounds like a bug we'd like to know about.  Please M-x report-emacs-bug.


        Stefan

Re: emacs 23 display slow over cable modem

[despen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> I compiled emacs 23.2.1 in my home dir on a linux cluster (amd 64 chips) at
>>> work.  I connect over VPN from home, where I have a cable modem.  For a long
>>> time, emacs 21.4 *run as an xwindows app* (not "emacs -nw" living in a
>>> terminal) has performed fine - after it starts (which may take some time),
>>> typing, switching buffers, etc is pretty instant.  But, doing the same thing
>>> in 23.2 gives much slower response.  Both work fine in -nw mode, but there
>>> are some reasons (keyboard mappings, multi-windows, mouse) why I like the
>>> full xwin app.  From my office, both xwin's run very fast.
>
> Sounds like a bug we'd like to know about.  Please M-x report-emacs-bug.

I've already done a bug report based on the

  "Why is Emacs so slow when used remotely?"

thread.

Was it received?  Was it clear enough?

Unlike other projects, I don't remember getting email on bug
reports for emacs as they change status.  Sort of leaves us
in the dark.

Re: emacs 23 display slow over cable modem

[Stefan Monnier]

> I've already done a bug report based on the
>   "Why is Emacs so slow when used remotely?"
> thread.
> Was it received?  Was it clear enough?

Yes, we recevied it, as you can see at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7092.

I see, then it is probably somewhat specific to dired.

> Unlike other projects, I don't remember getting email on bug
> reports for emacs as they change status.  Sort of leaves us
> in the dark.

We're not very good at using the bug-tracker, indeed (it's the right
place to submit reports, tho).


        Stefan

Re: emacs 23 display slow over cable modem

[despen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I've already done a bug report based on the
>>   "Why is Emacs so slow when used remotely?"
>> thread.
>> Was it received?  Was it clear enough?
>
> Yes, we recevied it, as you can see at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7092.
>
> I see, then it is probably somewhat specific to dired.

I think the OP complained about buffer list too.
I use Electric buffer list, it has tool tips and is easy
to get backed up if you mouse around it.
The mode line and window separators detect hover too and
seem to cause problems.

I just tried again, and I'm still seeing backed up tool tip windows
popping up as I type this in a local copy of Emacs.

>> Unlike other projects, I don't remember getting email on bug
>> reports for emacs as they change status.  Sort of leaves us
>> in the dark.
>
> We're not very good at using the bug-tracker, indeed (it's the right
> place to submit reports, tho).

Thanks.

I know I can disable tooltip mode but I don't see how to disable
all the hover stuff going on.  I think it's too much for remote
use.

Re: emacs 23 display slow over cable modem

[despen]

Tim X <timx@nospam.dev.null> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>> I know I can disable tooltip mode but I don't see how to disable all
>>> the hover stuff going on.  I think it's too much for remote use.
>>
>> Indeed "all the hover stuff" is designed with the assumption of a fast
>> and low-latency access to the X server.
>>
>> I must say I do not know how to make them work acceptably on a slow
>> connection.  A poor man's solution is to turn off those features, but as
>> you say it's not always easy to do it.
>>
>> Maybe we could provide a configuration variable that just forces Emacs
>> to ignore all mouse-movement events, as it used to in Emacs-20 (IIRC).
>> It would work by telling the server not to send it mouse-movement events
>> (except within the scope of a track-mouse, of course, so that
>> mouse-drags can provide feedback as is expected nowadays).
>>
>>
>>         Stefan
>
> That could be a good idea. Although I rarely run emacs in native X mode
> remotely over a WAN these days, preferring tramp most of the time, it is
> a pity that this feature no longer appears to work well. 
>
> For the OP, one solution is to use one of the X compression protocols.
> There are a couple of variants and most are fairly easy to setup. These
> greatly reduce the amount of X protocol traffic being sent and greatly
> improve the performance. Most Linux distros come with one or two
> variants as standard packages. 

I'm not the OP but I'm using ssh without -c.  The ssh man page says:

   Compression is  desirable on modem lines and  other slow connections,
   but will only slow down things on fast networks.

Ssh goes over a VPN which does compression.

I wouldn't mind having to add a dozen commands to my .emacs
but as far as I can tell, it can't be configured off.

Re: emacs 23 display slow over cable modem

[Tim X]

despen@verizon.net writes:

> Tim X <timx@nospam.dev.null> writes:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> I know I can disable tooltip mode but I don't see how to disable all
>>>> the hover stuff going on.  I think it's too much for remote use.
>>>
>>> Indeed "all the hover stuff" is designed with the assumption of a fast
>>> and low-latency access to the X server.
>>>
>>> I must say I do not know how to make them work acceptably on a slow
>>> connection.  A poor man's solution is to turn off those features, but as
>>> you say it's not always easy to do it.
>>>
>>> Maybe we could provide a configuration variable that just forces Emacs
>>> to ignore all mouse-movement events, as it used to in Emacs-20 (IIRC).
>>> It would work by telling the server not to send it mouse-movement events
>>> (except within the scope of a track-mouse, of course, so that
>>> mouse-drags can provide feedback as is expected nowadays).
>>>
>>>
>>>         Stefan
>>
>> That could be a good idea. Although I rarely run emacs in native X mode
>> remotely over a WAN these days, preferring tramp most of the time, it is
>> a pity that this feature no longer appears to work well. 
>>
>> For the OP, one solution is to use one of the X compression protocols.
>> There are a couple of variants and most are fairly easy to setup. These
>> greatly reduce the amount of X protocol traffic being sent and greatly
>> improve the performance. Most Linux distros come with one or two
>> variants as standard packages. 
>
> I'm not the OP but I'm using ssh without -c.  The ssh man page says:
>
>    Compression is  desirable on modem lines and  other slow connections,
>    but will only slow down things on fast networks.
>
> Ssh goes over a VPN which does compression.
>
> I wouldn't mind having to add a dozen commands to my .emacs
> but as far as I can tell, it can't be configured off.

The compression I'm referring to has nothing to do with ssh or even VPN
compression. 

The X protocol has a lot of duplicated data in its packets (it was not
designed for WAN connections). A number of people realised that
performance of X based applications would be greatly improved over
slower connections if some of the duplicated/redundent data was removed.
This resulted in a number of tools, such as dxpc and nxproxy that
attempt to improve the performance of X based applications over WAN
connections by removing some of the redundency/duplicated data sent as a
normal part ofthe X protocol. This differential compression is occuring
at the X protocol level and not at the ssh protocol level. 

In general, there is a trade off between speed and compression. There is
a point at which the cost of compressing and decompressing data is more
expensive (i,e, takes more time to perform) than just sending the data
'raw'. This can be especially true if the compression and decompression
algorithms being used rely on complex analysis where the speed of the
machines doing this work is a lot slower than the raw speed of the data
line. However, the X compression being used by the above tools is not
performming in-depth analysis and encoding/decodings - at least not in
the same sense as many compression techniques that favor space over
time. What they are really doing is stripping redundent data out of the
protocol. There is not a large encoding/decoding overhead as you
sometimes see with other forms of compression. 

Of course, this X protocol data is usually being forwarded over the ssh
layer and so ssh compression may also have an impact. However, if your
running a VPN, it may be possible to run a direct X connection and
bypass ssh, though this would depend on your VPN and remote network
firewalls etc. However, if you do go down this route, make sure you use
the xauth and not the xhost path to get display permissions working. It
is a bit more work, but a lot more secure. 

Tim

-- 
tcross (at) rapttech dot com dot au