emacs-devel
[Top][All Lists]
Advanced

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

Re: Gnu Emacs way slower than XEmacs


From: Kai Großjohann
Subject: Re: Gnu Emacs way slower than XEmacs
Date: Thu, 24 Apr 2003 09:36:45 +0200
User-agent: Gnus/5.090019 (Oort Gnus v0.19) Emacs/21.3.50 (gnu/linux)

David Abrahams <address@hidden> writes:

> "Eli Zaretskii" <address@hidden> writes:
>
>> Then how about profiling the lengthy operation?  See the instructions
>> in elp.el for more details.
>
> OK, the results are posted here:
>
>   http://users.rcn.com/abrahams/elp/
>
> I enabled profiling for gnus-*, imap-*, and nnimap-*.

Okay, it seems in both cases the function that takes long is
imap-wait-for-tag.  But in XEmacs it's much faster.

Could you do the following?

M-x find-function RET imap-wait-for-tag RET
C-n C-n         (move down a bit, not important how much)
M-x edebug-defun RET

Now invoke the same operation again that you invoked for the
profiles.  Emacs should show you the imap.el buffer with an arrow
indicating the current line.  Then you can use SPC to step through.

I'm guessing that the long delay will be in the call to
accept-process-output, and that this delay will be shorter in XEmacs
than in Emacs.

If that's really the case, then, indeed, it's the subprocess and
network I/O operations that need to be tweaked.

Hm.  I browsed the C source but didn't see anything there that's
obviously specific to Windows.  So I don't really have an idea what
to do if my conjecture is right.  But this was the first time I ever
looked at that code, and I'm no networking wizard, so I'm sure others
will have better ideas.
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)





reply via email to

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