Re: Gnu Emacs way slower than XEmacs

[Ben Wing]

actually it was kirill katsnelson who did most of the work on processes and
networks, although i [a] scrapped the synchronous process stuff and rewrote it
using async, [b] added the abstracted stream interface.

but basically, the old gnu emacs way involved trying to simulate select[] and
other unix operations using windows, ala cygwin.  kirill scrapped all of the
process and network code for both windows and unix and rewrote it using an
abstraction layer that obviated the need to play games.  it doesn't look like
this has changed significantly in recent gnu emacsen.  there is no obvious
reason why emulation *has* to be slower, but in practice it often gets that way
because [a] the low-level code sometimes does unnecessary things to make the
emulation work., [b] it is hard to sort out what's really going on, and hence
[c] people are reluctant to make real changes.  as it is, i have seen a few
patches come into xemacs over the years from random contributors to speed up the
process/network code by putting a sleep or yield or buffering change or whatever
in certain critical places, and it seems less likely these would have appeared
without the clean abstracted design.

we do use async i/o with winsock.

ben

----- Original Message -----
From: "Jason Rumney" <address@hidden>
To: <address@hidden>
Cc: <address@hidden>
Sent: Tuesday, April 22, 2003 11:43 PM
Subject: Re: Gnu Emacs way slower than XEmacs


>
> Hi Ben, can you answer the following question for me?
> A simple yes or no is sufficient, we are trying to determine whether
> there is a simple explanation for XEmacs being noticeably faster than
> GNU Emacs for network operations on Windows, or if it is due to a bug
> in GNU Emacs.
>
>
> "Stephen J. Turnbull" <address@hidden> writes:
>
> > >>>>> "Jason" == Jason Rumney <address@hidden> writes:
> >
> >     Jason> Does XEmacs implement non-blocking sockets on Windows?
> >
> > I don't know.  Ask Ben Wing <address@hidden>.  I know he's done a lot
> > of work on processes, much of it intended to make processes work
> > efficiently on Windows within the Unix-centric context of the rest of
> > XEmacs.  He may have done so; I'm sure it would be high on his
> > priority list.
>
>