When I work from home, I login from one Linux machine to another using
ssh -X over a high-speed Internet connection, using my home machine as
an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
I am finding that opening a file or switching buffers by middle-
clicking in dired or the buffer menu takes approximately 20-30
seconds. With XEmacs it takes less than one second. I hope I am doing
something wrong that can be corrected, because I'll grow old sitting
around that long every time I open a file or switch buffers. Any
suggestions? Thanks.
Russ P.
Did you file a bug report?
Emacs seems a little over-active in dired-mode.
I'm running at least one emacs remotely too.
Just hovering over a name in dired causes a packet storm.
My first guess was that it was tooltip-mode so I toggled that
off.
Dired is still doing something during hover though
in the mode line it tries to tell me which button to push.
Each time it does that, I get a mini-packet storm.
(I can see my packet monitor graph move up.)
Maybe someone knows how to kill over active help in Dired?
No. I don't know if this behavior is a bug or just poor performance.
(Nor do I know, off hand, how to file a bug report.)
This is disappointing. As far as I can tell, Emacs seems to be
essentially unusable for remote usage. I can't believe I am the only
one who has noticed this problem. Am I the only one who uses Emacs/
XEmacs to work remotely over ssh -X?
Russ P
Russ> On Sep 20, 6:40 pm, des...@verizon.net wrote:
>> Did you file a bug report?
Russ> No. I don't know if this behavior is a bug or just poor performance.
Russ> (Nor do I know, off hand, how to file a bug report.)
Russ> This is disappointing. As far as I can tell, Emacs seems to be
Russ> essentially unusable for remote usage. I can't believe I am the only
Russ> one who has noticed this problem. Am I the only one who uses Emacs/
Russ> XEmacs to work remotely over ssh -X?
I can't reproduce the problems. Start-up time of GNU Emacs 23.2.1 called with
"-Q" on my up to date remote Debian Unstable machine over ssh -X to my nearly
identical system over here is basically the same as GVim's; file opening and
buffer switching, typing and calling commands is all right. The menus are a
little bit sluggish and navigating in dired via mouse clicks really is
sloooow---close to 20 seconds. Keyboard navigation works fast, though.
Russ> Russ P
Toto
--
Aaachen University of Technology -- now even further ahead...
Try clicking on a file in dired. (You must use the mouse.)
> On Sep 20, 6:40 pm, des...@verizon.net wrote:
>> "Russ P." <russ.paie...@gmail.com> writes:
>> > As I explained a few days ago, I am trying to switch from XEmacs to
>> > Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
>> > got my .emacs file debugged, but now I am finding that Emacs seems to
>> > be very slow when used remotely.
>>
>> > When I work from home, I login from one Linux machine to another using
>> > ssh -X over a high-speed Internet connection, using my home machine as
>> > an X terminal for my work machine. I am using Emacs 23.2.1 on Red Hat.
>> > I am finding that opening a file or switching buffers by middle-
>> > clicking in dired or the buffer menu takes approximately 20-30
>> > seconds. With XEmacs it takes less than one second. I hope I am doing
>> > something wrong that can be corrected, because I'll grow old sitting
>> > around that long every time I open a file or switch buffers. Any
>> > suggestions? Thanks.
>>
>> Did you file a bug report?
>
> No. I don't know if this behavior is a bug or just poor performance.
> (Nor do I know, off hand, how to file a bug report.)
Poor performance is a bug.
To send a bug report, click on Help, select Send Bug Report...
> This is disappointing. As far as I can tell, Emacs seems to be
> essentially unusable for remote usage. I can't believe I am the only
> one who has noticed this problem. Am I the only one who uses Emacs/
> XEmacs to work remotely over ssh -X?
As I said, I use emacs remotely all the time.
I actually one of the reasons I moved from XEmacs to Emacs was
the greatly improved performance.
The specific issue you are having has to do with dired and
it's "hover" feature. I was hoping someone would explain
how to turn the too helpful feature off.
I might dig into dired myself, but no promises.
A few things to try ...
1. turn off tooltip mode
2. Try running with -nw to turn off X and only have a terminal UI and
see what the performance is like. this will let you know if the problem
is basic emacs or the X protocol stuff
3. Have you considered running tramp rather than a remote emacs? I've
not bothered with a remote emacs for a long time, preferring to run
tramp (especially with tramps support for remote execution of commands
etc).
4. Have you experimented with ssh compression? Sometimes you need to try
various values to get the optimal setting for your connection. Most X
protocol packets are quite small and too high a setting for compression
can actaully slow things down.
5. When I did run remote X based emacs versions, I found using one of
the X compression protocols gave a huge performance improvement. From
memory, the one I used was something like xdcp (X differential
compression protocol or something similar). I believe recent X.org
versions come with support for such protocols. Maybe look at setting
this up.
HTH
Tim
--
tcross (at) rapttech dot com dot au
For a distant machine with an ssh connection, you are usually quite
better off running Emacs on your _own_ machine and just accessing files
remotely.
Something like
C-x C-f /user...@my.remote.host:local.filename RET
This will open an ssh session under username on my.remote.host and use
shell commands for transferring the file to your local Emacs.
Even things like
M-x compile RET
should work reasonably well (executing on the remote host with output to
a window in your local Emacs).
Much better than having to update a graphical display, and you need not
bother installing and maintaining an Emacs on the remote site.
--
David Kastrup
> A few things to try ...
>
> 1. turn off tooltip mode
Yes. Anything graphic.
> 2. Try running with -nw to turn off X and only have a terminal UI and
> see what the performance is like. this will let you know if the problem
> is basic emacs or the X protocol stuff
This is not useful, if you only work with text. The X protocol is not
significantly worse than any other terminal protocol to send over text.
> 3. Have you considered running tramp rather than a remote emacs? I've
> not bothered with a remote emacs for a long time, preferring to run
> tramp (especially with tramps support for remote execution of commands
> etc).
>
> 4. Have you experimented with ssh compression? Sometimes you need to try
> various values to get the optimal setting for your connection. Most X
> protocol packets are quite small and too high a setting for compression
> can actaully slow things down.
Also, on a trusted network (ie. a LAN), you could bypass ssh, and just
send X directly over the LAN.
> 5. When I did run remote X based emacs versions, I found using one of
> the X compression protocols gave a huge performance improvement. From
> memory, the one I used was something like xdcp (X differential
> compression protocol or something similar). I believe recent X.org
> versions come with support for such protocols. Maybe look at setting
> this up.
--
__Pascal Bourguignon__ http://www.informatimago.com/
> 3. Have you considered running tramp rather than a remote emacs? I've
> not bothered with a remote emacs for a long time, preferring to run
> tramp (especially with tramps support for remote execution of commands
> etc).
I was not aware of tramp. Thanks for mentioning it. I see from the
docs that it is included with Emacs since version 22. Can you give me
a clue how to find it in Emacs and use it?
I'm wondering how it will work with Ensime (Emacs-based IDE for
Scala).
Russ P.
> Tim X <ti...@nospam.dev.null> writes:
>
>> A few things to try ...
>>
>> 1. turn off tooltip mode
>
> Yes. Anything graphic.
>
>
>> 2. Try running with -nw to turn off X and only have a terminal UI and
>> see what the performance is like. this will let you know if the problem
>> is basic emacs or the X protocol stuff
>
> This is not useful, if you only work with text. The X protocol is not
> significantly worse than any other terminal protocol to send over text.
Font rendering/antialiasing/composition nowadays happens mostly at the
client side if I am not mistaken. That makes the X protocol much worse
even with text.
--
David Kastrup
You haven't mentioned how you are running the remote Emacs. I presume via X
windows?
I have never been happy with the performance of X windows myself. If I have to
access remote stuff, my solutions are:
1. To try remote file access from a local Emacs session. You can tunnel
various file access protocols through SSH (I tunnel SMB from Windows), and
there is also Emacs's own tramp which allows you to access remote files.
2. Run Emacs on the remote machine and connect to it from a locally run
emacsclient.
Cheers,
Uday
That's not what I observe. It's possible for an application to deal
with characters itself and send bitmaps but normally, and it looks
like it's what emacs does, it sends only the strings and the font
rendering is done in the X server.
For bitmap fonts. I don't think the X protocol channels antialiased
fonts yet. Usually xfs (the font server) runs on the client side of the
connection.
--
David Kastrup
Let's get specific. IIRC, antialiased fonts appeared on emacs 23. So
there would be a risk of slow text mode with emacs >=23, but we'd be
assured to get a fast text mode with emacs <=22. Right?
> This is disappointing. As far as I can tell, Emacs seems to be
> essentially unusable for remote usage. I can't believe I am the only
> one who has noticed this problem. Am I the only one who uses Emacs/
> XEmacs to work remotely over ssh -X?
I used to use emacs over X/ssh on remote links, but finally had to give
up: with recent versions it has become almost unusable.
Starting it up takes half a minute, it's a bit slow at everything and
you'll have to remember to avoid using certain features: e.g. hitting
Ctrl-K (to delete a line) takes about 10 seconds; same goes for anything
that will (possibly as a side-effect) copy something to the clipboard.
In the end I moved to "emacs -nw" and forgot about X entirely.
Of course, on a LAN, it's a whole different story and I'm using
emacs/X/ssh everyday.
Just my two cents
bye
av.
> David Kastrup <d...@gnu.org> writes:
>
>> p...@informatimago.com (Pascal J. Bourguignon) writes:
>>
>>> Tim X <ti...@nospam.dev.null> writes:
>>>
>>>> A few things to try ...
>>>>
>>>> 1. turn off tooltip mode
>>>
>>> Yes. Anything graphic.
>>>
>>>
>>>> 2. Try running with -nw to turn off X and only have a terminal UI
>>>> and see what the performance is like. this will let you know if
>>>> the problem is basic emacs or the X protocol stuff
>>>
>>> This is not useful, if you only work with text. The X protocol is
>>> not significantly worse than any other terminal protocol to send
>>> over text.
>>
Not my practical experience. When I run I don't use the menus, mouse or
toolbar. However, -nw is much faster than X. The only issue I've had is
with different local X terminals 'grabbing' some keys, making some key
combinations harder to achieve in the remote emacs. Depending on yhour
window manager and terminal emulator, it may be necessary to tweak
things to get the full list of keys to the remote emacs.
However, my recommendation for the OPs question is to run one of the X
compression protocols. X was designed for a LAN rather than a WAN and
has a lot of overhead. However, much of this is easily compressed.
In the past, on a 56k modem, I used dxcp with good results. Still a bit
slow, but usable. Anyone using DSL should get much better results.
There is also nxproxy, which I've not used, but which is based on the
concepts in dxcp.
Setting up dxcp was fairly trivial.
I'd still like to see future versions of Emacs with improved network
performance. For whatever reason, XEmacs seems to do much better in
that regard.
Russ P.
> Thanks for all the replies and suggestions. At this point, I am
> changing my strategy. I intend to use rsync and git to keep my home
> and work computers synchronized. Then I will be able to use Emacs
> locally and not worry about network delays. Maybe I should have done
> this a while back, but better late than never. I just learned how to
> use rsync through an ssh tunnel, and that is what I need (see my post
> at comp.unix.shell on that).
>
> I'd still like to see future versions of Emacs with improved network
> performance. For whatever reason, XEmacs seems to do much better in
> that regard.
>
If remote editing is all you require, tramp mode is really good. Once
you setup ssh and ssh-agent, all you need to do is
C-x C-f /hostname:path/to/file
I find setting the tramp cache directory to a local temp directory helps
on slow or unreliable ssh connections that drop out. A lot easier than
maintaining mirirs with rsynch (which is what I use to do).
If you need to use other tools on the files and want things to look like
they are local, sshfs is also useful.
If you don't like it, then it qualifies to file a bug report.
> (Nor do I know, off hand, how to file a bug report.)
Menu "Help" entry "Send bug report..." should do it, as should M-x
report-emacs-bug. Note that it's also the right way to send
feature requests.
Stefan
Apparently it doesn't have to be that way: client-side rendering
requires sending pixmaps to the server, whereas server-side rendering
requires sending font-metadata to the client. Depending on the
particular situation either one can be faster than the other.
Apparently, if the pixmaps get appropriately cached, the amount of data
in either case, for some mythical "typical" situation, has been measured
to be comparable, while the client-side rendering benefits from the fact
the sending pixmaps to the server is much more latency-tolerant than
querying font metadata, which requires a lot round-tripping.
It sounded very counter-intuitive to me, but it came from some USENIX
article by one of the head X guys, IIRC.
Stefan
For Emacs-21, we made a specific effort to get remote use working
"efficiently", in response to complaints that it was a lot slower than
Emacs-20. I guess we need to do the same now.
The best for that is to give (via M-x report-emacs-bug) very concrete,
easy to reproduce steps that are noticably slower in Emacs-23 than in
Emacs-22 (or Emacs-21), so we can analyze the network traffic in those
two cases and try to improve it.
Stefan
> As I explained a few days ago, I am trying to switch from XEmacs to
> Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
> got my .emacs file debugged, but now I am finding that Emacs seems to
> be very slow when used remotely.
>
> When I work from home, I login from one Linux machine to another using
> ssh -X
is sshfs not an option for you?
> I used to use emacs over X/ssh on remote links, but finally had to
> give up: with recent versions it has become almost unusable.
> Starting it up takes half a minute, it's a bit slow at everything and
> you'll have to remember to avoid using certain features: e.g. hitting
> Ctrl-K (to delete a line) takes about 10 seconds; same goes for
> anything that will (possibly as a side-effect) copy something to the
> clipboard.
XEmacs had the same problem a few years ago but in the end a solution
was found, sorry i don't remember the exact details (available with
some searching on xemacs-beta archives)
The clipboard issue was XEmacs using the X11 clipboard for kills.
A switch could turn it off.
I haven't noticed a similar issue with Emacs.
Some where in my .emacs I may still be turning it off.
I was not aware of it, but I'll check it out. Thanks.
I looked up sshfs, and it looks interesting. Before I go to the
trouble of installing it, can anyone tell me something about its
performance and how it should be used. Would I open Emacs locally on
my home machine and edit remote files? What are the delays like?
Thanks.
Russ P.
I'll try to clarify things. I'm assuming you have ssh setup and use
ssh-agent (not strictly necessary, but makes life a lot easier by
avoiding the need to enter passwords when loging into the remote host)
You have three options for editing remote files using emacs.
1. Run emacs rmotely. This approach has given you performance issues.
You could get better performance running it without X support i.e.
issuing emacs -nw on the remote machine, but you then don't have menus
or full mouse support. If you still want to run reotely with X, you only
remaining option is to use one of the X compression protocols, such as
dxcp or nxproxy.
2. Use tramp to edit the files remotely. Run emacs on the local machine
as usual. When you want to edit a file on the remote host, just do
C-x C-f /remote-hostname:path/to/file/to/edit
There are a few tweaks you can do to improve performance, such as
setting a local temp directory, but it should just work 'out of the box'
(depending on your version of emacs). I've been using tramp mode for
about 8 years. It has been part of emacs for the last two or three
releases.
3. Use sshfs. This is similar in concept to using NFS. You 'mount' a
remote file system locally over the ssh protocol. The remote file system
is mounted on a local directory. You can then cd to that directory and
view/edit files as if they were local files. Of course, performance may
be a bit slower than a real local file due tot he ssh overhead
anddepending on your network stability, you can get drop outs.
Sometimes, you need to tweak the sshfs otptions to get the best
performance and you may need to turn on auto-reconnect etc.
As this makes the remote filesystem appear as a local filesystem to the
OS, you just edit the files as if they were local files.
I find this option very useful when I want to manipulate the files with
other non-emacs tools. If I only want to edit the file, tramp is easier.
Performance is difficult to quantify as it depends a lot on your network
connection. I use a pretty fast DSL link and connect using ssh inside an
SSL VPN tunnel. With either tramp or sshfs, the only time you notice any
delay is when you first open the file and when you save it - the delay
is small, though of course it can be longer if you have other network
activity happening at the same time you open/save a file (i.e. mail
download, web browsing etc). To get optimal performance, depending on
your environment, you may need to tweak things. However, I've found most
of the time, the defaults work fine.
> On Sep 24, 8:45 am, Giacomo Boffi <giacomo.bo...@polimi.it> wrote:
>> "Russ P." <russ.paie...@gmail.com> writes:
>> > As I explained a few days ago, I am trying to switch from XEmacs to
>> > Emacs so I can use Ensime (an Emacs-based IDE for Scala). I finally
>> > got my .emacs file debugged, but now I am finding that Emacs seems to
>> > be very slow when used remotely.
>>
>> > When I work from home, I login from one Linux machine to another using
>> > ssh -X
>>
>> is sshfs not an option for you?
>
> I looked up sshfs, and it looks interesting. Before I go to the
> trouble of installing it, can anyone tell me something about its
> performance and how it should be used.
here i am
> Would I open Emacs locally on my home machine and edit remote files?
yes, you "cd mount_point" and the it's normal editing
> What are the delays like?
if you're on a link barely not fast enough for X, very short
the real difference between sshfs and tramp is that sshfs is
transparent to all programs, tramp is only for emacs
if Ensime uses external utilities, sshfs would seem more appropriate
--
la panna resta piů pannosa. -- Ruggine, in IHC
Another difference is that with Tramp, you can have processes (like M-x
compile) running on the remote host, which may be much better or much
worse, depending on what you need.
Stefan
>> the real difference between sshfs and tramp is that sshfs is
>> transparent to all programs, tramp is only for emacs
>
> Another difference is that with Tramp, you can have processes (like
> M-x compile) running on the remote host,
that's interesting... does it work with auctex too?
tia
g
No idea: try it and if it doesn't work, report it to the AUCTeX
maintainers: it's easy to make it work (typically replace call-process
by process-file or start-process by start-file-process).
Stefan