help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: emacs24 slower than emacs23


From: Stefan Monnier
Subject: Re: emacs24 slower than emacs23
Date: Fri, 07 Feb 2014 23:37:36 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> ~/.emacs and everything works, except that emacs24 is noticeably slower than
> emacs23, sometimes painfully so.

Such slow down is usually considered as a bug, so you might like to M-x
report-emacs-bug about that, tho please only do it for cases where you can
clearly measure the performance difference and have a repeatable test case.

> Most of the slowness is tolerable, but one issue is painful.  When I'm using
> emacs24 on "X over SSH" and start to select portion of text (region) by
> pressing Ctrl-Space, the cursor movement becomes extremely slow, that is, it
> takes a lot of time to select a region.

It's probably linked to select-active-regions.  IOW if you (setq
select-active-regions nil) or (setq select-active-regions 'only) in your
.emacs it might work around the problem.  Maybe this workaround is the
best we can do, but I doubt it.  So if you can provide enough details
that it can be reproduced, please report this as a bug so that we can
try and see how we can do better.

> Are there some settings to adjust to fix this problem?  I run emacs on an
> Debian server and my local machine is a Mac OS X machine running Xquartz.

Sometimes the problem with features like select-active-regions is linked
to an external tool that pro-actively copies the selection, so instead of
having a single short message from Emacs saying "I own the selection",
we have this one message followed by a request from that other tool to
send over the selection, followed by more messages actually doing
the send.
And this gets repeated for every cursor movement command.

In many such cases the problem is really in the external tool being too
eager to get the selection.

> minority.  If emacs becomes unusable, I'll probably have to stop X over SSH
> and perhaps rely on a cloud-shared directory (like Dropbox) or use tramp on
> local emacs.

I've heard several reports that Emacs is "too slow for X over SSH"
nowadays.  Back in Emacs-21 we had a similar problem, and we fixed it
("it" here is a simplification, since it was linked to several
problems).  We should do the same now, but that requires not just work
on our side, but also on the side of users of "X over SSH" to help us
track down the problems (e.g. using xtruss).

If you're up for it, then please do report those bugs and help us track
down those bandwidth thieves.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]