[levoy@cs.stanford.edu: Poor performance over DSL link]

[levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

Could you please help him figure out what causes this traffic?

------- Start of forwarded message -------
Envelope-to: rms@gnu.org
Delivery-date: Sat, 07 Sep 2002 14:52:11 -0400
From: "Marc Levoy" <levoy@cs.stanford.edu>
To: bug-gnu-emacs@gnu.org
Subject: Poor performance over DSL link
Sender: bug-gnu-emacs-admin@gnu.org
Date: 7 Sep 2002 11:51:19 -0700

Dear Emacs maintainers,

I just upgraded from Emacs 20.7 to 21.2, and I am suddenly seeing high traffic
on my DSL link whenever the mouse is positioned over my Emacs window, even if
my hands are off the keyboard and mouse.  Under 20.7, if I didn't touch the
keyboard or mouse, there was no network traffic.  Emacs 21.2 seems sluggish
over a DSL link; could this be why?

More details:

I am running "GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll
bars) of 2002-04-08 on porky.devel.redhat.com" on a Linux 7.3 system and
displaying through Exceed 7.0 to a Windows 2000 system.  However, I see
the same problem displaying through VNC, so I suspect the problem arises
from within Emacs.  (If I move the mouse off the Emacs window, the extra
traffic stops.)

I have tried turning off scroll bars and tooltips, but neither has any effect.
I have searched the Internet for similar reports, and I see various complaints
about the performance of various versions of Emacs over slow connections, but
nothing that seems relevant to fixing the problem.

Is there something else I can disable in order to stop this network traffic
and restore my editing performance?

- -Marc Levoy
 Associate Professor
 Computer Science Department
 Stanford University


_______________________________________________
Bug-gnu-emacs mailing list
Bug-gnu-emacs@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
------- End of forwarded message -------

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Kim F. Storm]

From PROBLEMS:

* Improving performance with slow X connections

If you don't need X Input Methods (XIM) for entering text in some
language you use, you can improve performance on WAN links by
configuring Emacs with option `--without-xim'.  Configuring Emacs
without XIM does not affect the use of Emacs' own input methods, which
are part of the Leim package.

If the connection is very slow, you might also want to consider
switching off scroll bars, menu bar, and tool bar.


Richard Stallman <rms@gnu.org> writes:

> Could you please help him figure out what causes this traffic?
> 
> From: "Marc Levoy" <levoy@cs.stanford.edu>
> Subject: Poor performance over DSL link
> To: bug-gnu-emacs@gnu.org
> Date: 7 Sep 2002 11:51:19 -0700
> 
> Dear Emacs maintainers,
> 
> I just upgraded from Emacs 20.7 to 21.2, and I am suddenly seeing high traffic
> on my DSL link whenever the mouse is positioned over my Emacs window, even if
> my hands are off the keyboard and mouse.  Under 20.7, if I didn't touch the
> keyboard or mouse, there was no network traffic.  Emacs 21.2 seems sluggish
> over a DSL link; could this be why?
> 
> More details:
> 
> I am running "GNU Emacs 21.2.1 (i386-redhat-linux-gnu, X toolkit, Xaw3d scroll
> bars) of 2002-04-08 on porky.devel.redhat.com" on a Linux 7.3 system and
> displaying through Exceed 7.0 to a Windows 2000 system.  However, I see
> the same problem displaying through VNC, so I suspect the problem arises
> from within Emacs.  (If I move the mouse off the Emacs window, the extra
> traffic stops.)
> 
> I have tried turning off scroll bars and tooltips, but neither has any effect.
> I have searched the Internet for similar reports, and I see various complaints
> about the performance of various versions of Emacs over slow connections, but
> nothing that seems relevant to fixing the problem.
> 
> Is there something else I can disable in order to stop this network traffic
> and restore my editing performance?
> 
> - -Marc Levoy
>  Associate Professor
>  Computer Science Department
>  Stanford University
> 
> 
> _______________________________________________
> Bug-gnu-emacs mailing list
> Bug-gnu-emacs@gnu.org
> http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs
> ----------
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel
> 
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Marc Levoy]

Kim (and Richard),

Thanks for the quick response.  I had already seen those suggestions (turning
off XIM, and disabling scroll bars, the menu bar, and the tool bar) on a web
page.  I tried all except turning off XIM, and it didn't help.

As it happens, I finally realized (by watching the rhythm of the traffic)
that Emacs 21's software blinking cursor was causing the traffic.  I disabled
it using:

	(if (fboundp 'blink-cursor-mode)
		(blink-cursor-mode -1))

and the extra traffic disappeared.  You might suggest this tweak to people
with DSL (or slower) links.

-Marc

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Kim F. Storm]

"Marc Levoy" <levoy@cs.stanford.edu> writes:

> Kim (and Richard),
> 
> Thanks for the quick response.  I had already seen those suggestions (turning
> off XIM, and disabling scroll bars, the menu bar, and the tool bar) on a web
> page.  I tried all except turning off XIM, and it didn't help.
> 
> As it happens, I finally realized (by watching the rhythm of the traffic)
> that Emacs 21's software blinking cursor was causing the traffic.  I disabled
> it using:
> 
> 	(if (fboundp 'blink-cursor-mode)
> 		(blink-cursor-mode -1))
> 
> and the extra traffic disappeared.  You might suggest this tweak to people
> with DSL (or slower) links.

We should add this to PROBLEMS.

Since the other suggestions mentioned there to improve performance can
be controlled via the Options->Show/Hide menu [PROBLEMS could mention
that], we might consider to add a menu item for controlling the
blinking cursor as well, e.g Option->Show/Hide->Blinking Cursor

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

    As it happens, I finally realized (by watching the rhythm of the traffic)
    that Emacs 21's software blinking cursor was causing the traffic.

I am surprised that blinking every .5 second causes so much traffic.

Does this cure the sluggishness too?

    We should add this to PROBLEMS.

Yes, once we are finished understanding the situation.

    Since the other suggestions mentioned there to improve performance can
    be controlled via the Options->Show/Hide menu [PROBLEMS could mention
    that], we might consider to add a menu item for controlling the
    blinking cursor as well, e.g Option->Show/Hide->Blinking Cursor

Ok.

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     As it happens, I finally realized (by watching the rhythm of the traffic)
>     that Emacs 21's software blinking cursor was causing the traffic.
> 
> I am surprised that blinking every .5 second causes so much traffic.
> 
> Does this cure the sluggishness too?
> 
>     We should add this to PROBLEMS.
> 
> Yes, once we are finished understanding the situation.

There were other X-related problems on slow WAN links.  

AFAIR the problem was related to emacs constantly allocating and
releasing colors on the X-server, and requesting the list of fonts
from the X-server.  

I made some changes for 21.1 (which Gerd used) to improve this by
caching some of the information, and it did make a fairly significant
difference.

But there were still several areas which could be improved - but it
would be non-trivial to do so, either because X-servers have different
capabilities, or because the "excessive" traffic was partially caused
by some of the X-library functions.  

So it was put on hold until after 21.1.  (Un)fortunately, in the
meantime I've got a much faster WAN link (1024/256 ADSL), so I no
longer experience the problems I had with the 64k ISDN link, and thus
I don't have a personal interest in improving this anymore.

I'm afraid I no longer have the correspondance with Gerd and Richard
on this issue; any chance that either of you still have a copy [I think
my email address at the time was stormware@get2net.dk] ?

> 
>     Since the other suggestions mentioned there to improve performance can
>     be controlled via the Options->Show/Hide menu [PROBLEMS could mention
>     that], we might consider to add a menu item for controlling the
>     blinking cursor as well, e.g Option->Show/Hide->Blinking Cursor
> 
> Ok.

Would the maintainer of the "show/hide" menu please do this?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

    But there were still several areas which could be improved - but it
    would be non-trivial to do so, either because X-servers have different
    capabilities, or because the "excessive" traffic was partially caused
    by some of the X-library functions.  

What areas are they?  Maybe someone else would like to work on it.
At very least we can put them in etc/TODO.

    I'm afraid I no longer have the correspondance with Gerd and Richard
    on this issue; any chance that either of you still have a copy [I think
    my email address at the time was stormware@get2net.dk] ?

If I received the messages, I still have them.  What time period should
I search?

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     But there were still several areas which could be improved - but it
>     would be non-trivial to do so, either because X-servers have different
>     capabilities, or because the "excessive" traffic was partially caused
>     by some of the X-library functions.  
> 
> What areas are they?  Maybe someone else would like to work on it.
> At very least we can put them in etc/TODO.

It's been a long time, but I used Ethereal to trace the X traffic, and it
was quite obvious that the same sequences of events were repeated over
and over again...

IIRC, it had to do with allocating colors (or pixels?) in the X
server, updating [tiny parts of the display], and then deallocating
the colors - and doing that over and over for every tiny update.

I discussed ways to cache this information with Gerd, but it was
non-trivial because different X-servers had different number of
available colors/pixels, so it seemed to be difficult to do in a
general way.

> 
>     I'm afraid I no longer have the correspondance with Gerd and Richard
>     on this issue; any chance that either of you still have a copy [I think
>     my email address at the time was stormware@get2net.dk] ?
> 
> If I received the messages, I still have them.  What time period should
> I search?

Try January/February 2001 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

    IIRC, it had to do with allocating colors (or pixels?) in the X
    server, updating [tiny parts of the display], and then deallocating
    the colors - and doing that over and over for every tiny update.

Can anyone identify which parts of the code in Emacs do this?

    I discussed ways to cache this information with Gerd, but it was
    non-trivial because different X-servers had different number of
    available colors/pixels, so it seemed to be difficult to do in a
    general way.

I am sure it must be possible.  Since this seems to be causing a
significant annoyance for users, I think we should talk about it here.

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

I searched my mail in Jan/Feb 2001 for stormware@get2net.dk
and did not find it.

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

Here is the old message.

From: "Kim F. Storm" <storm@filanet.dk>
To: rms@gnu.org
CC: miles@gnu.org, storm@filanet.dk, emacs-pretest-bug@gnu.org
In-reply-to: <200012121602.JAA23121@wijiji.santafe.edu> (message from Richard
	Stallman on Tue, 12 Dec 2000 09:02:15 -0700 (MST))
Subject: Re: Performance running emacs with X over 64 kbps link.
References: <200012072142.eB7LgkF24504@mail.filanet.dk>
	<200012081646.JAA14693@wijiji.santafe.edu>
	<200012110930.eBB9UrF06342@mail.filanet.dk>
	<200012111700.KAA21073@wijiji.santafe.edu> <buoofyizcn6.fsf@mcspd15.ucom.lsi.nec.co.jp> <200012121602.JAA23121@wijiji.santafe.edu>
Content-Type: text
Content-Length: 1997

> Date: Tue, 12 Dec 2000 09:02:15 -0700 (MST)
> From: Richard Stallman <rms@gnu.org>
> 
>     Optimizing emacs' wire efficiency when using the X protocol may be
>     interesting but there are certainly many more important things to do...
> 
> I agree it is not of first-level importance.
> And it makes sense to tell people in this situation
> "Turn off features A, B and C for faster operation."
> 
> Still, it does matter to some extent.  It could be worth figuring out
> which features to advise them to turn off, and if something is
> gratuitously slow in how it uses X, speeding it up would be good for
> everyone.

I have been digging a little further into this issue.
I was wondering why emacs was so slow during start-up (+ 1 minute)
especially the noticeable delay between messages like
	Loading some-file.elc...
and
	Loading some-file.elc...done

It seemed that every package that uses 'defface' or 
actively manipulates the x-frame parameters are subject
to a several seconds load time.

I then used ethereal to trace on ppp0, and it turns out that emacs
is doing multiple calls to XListFonts(), XLookupColor() and
XAllocColor() - for the same font pattern and colors...

Since there is obviously no caching of the information read
from the X-server, it repeats those requests... which in
total causes a significant delay in emacs startup.

Totally, emacs exchanges ~1800 X11 (and TCP) packets
with the X-server before it is ready for use...  after some
75 seconds.  [this is when I delay the loading of .emacs
until the initial frame is properly displayed; without
that hack, loading emacs takes twice as long -- see my
previuos mails explaining this].

I don't know whether it is legal to cache any of this 
information, but doing so would probably make a significant
improvement in start-up time over slow links - any maybe
a small improvement in general.

-- 
Kim F. Storm  <storm@filanet.dk>      http://www.filanet.dk
Filanet Europe A/S    Herlev Hovedgade 82C,1 DK-2730 Herlev

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

	Does this [turning off blinking] cure the sluggishness too?

    To be frank, no; Emacs 21.2 seems more sluggish over DSL than Emacs 20.5 was.
    (I used Emacs 20.7 only for a week - not long enough to notice its speed.)

I had a feeling this would not solve the problem.
Something else must be causing the sluggishness.

Does anyone know of some X tools that could be used to figure
out what messages are being transmitted that cause the slowness?

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Gerd Moellmann]

Richard Stallman <rms@gnu.org> writes:

> Does anyone know of some X tools that could be used to figure
> out what messages are being transmitted that cause the slowness?

Xmon or Xscope might do this.

From an FAQ:

        333) Where can I get the xmon or xscope programs to trace my X        
                                                                              
 ---------------------------------------------------------------------------  
protocol?
[Last modified: Mar 96]

Answer: Both are included in the contrib section of X11R5:
ftp://ftp.x.org/pub/R5/

Xmon is also available at: ftp://ftp.x.org/contrib/devel_tools/ and
ftp://ftp.crl.research.digital.com/pub/X11/contrib/devel_tools/

Ken Lee

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

    If you don't need X Input Methods (XIM) for entering text in some
    language you use, you can improve performance on WAN links by
    configuring Emacs with option `--without-xim'.  Configuring Emacs
    without XIM does not affect the use of Emacs' own input methods, which
    are part of the Leim package.

Can we add a run-time feature to Emacs to disable the use of them?
Would that get the same speedup?

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     If you don't need X Input Methods (XIM) for entering text in some
>     language you use, you can improve performance on WAN links by
>     configuring Emacs with option `--without-xim'.  Configuring Emacs
>     without XIM does not affect the use of Emacs' own input methods, which
>     are part of the Leim package.
> 
> Can we add a run-time feature to Emacs to disable the use of them?
> Would that get the same speedup?

It seems like a fairly trivial change.

However, it is not adequate to simply make a variable to control this,
as the decision whether to actually use XIM would then have to be made
before creating the first frame, so setting that variable to "don't
use XIM" too late will not have any effect.

The proper solution is probably to make a function to enable/disable XIM on
an X display; as I see it, the use of XIM is actually per-display, so this
would be more flexible than the current compile-time constant.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> However, it is not adequate to simply make a variable to control this,
> as the decision whether to actually use XIM would then have to be made
> before creating the first frame, so setting that variable to "don't
> use XIM" too late will not have any effect.

Is it really impossible to turn off XIM in an existing window?
That seems like a bug in X...

-Miles
-- 
Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Miles Bader]

storm@cua.dk (Kim F. Storm) writes:
> So that very trivial change would not suffice; a function based
> interface to turn XIM off or on is needed

It could still use a variable as the user-interface, if that's better.
[e.g., in an appropriate place, do `if (xim_enabled != last_xim_enabled)...']

> making the changes somewhat less trivial.

Indeed...

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: [levoy@cs.stanford.edu: Poor performance over DSL link]

[Richard Stallman]

    The proper solution is probably to make a function to enable/disable XIM on
    an X display; as I see it, the use of XIM is actually per-display, so this
    would be more flexible than the current compile-time constant.

That would be a good approach.  Would you like to do it?