unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Michael Mauger <mmaug@yahoo.com>
Subject: Re: W32 to AIX performance
Date: Mon, 3 Jul 2006 18:11:59 +0000 (UTC)	[thread overview]
Message-ID: <loom.20060703T195504-934@post.gmane.org> (raw)
In-Reply-To: 20060629031018.65975.qmail@web60324.mail.yahoo.com

Michael Mauger <mmaug <at> yahoo.com> writes:

> 
> --- "Kim F. Storm" wrote:
> 
> > Michael Mauger writes:
> > 
> > > I'm currently using GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-
05-02 
> > > on XP.  
> > >
> > > I use an up-to-date cygwin ssh to connect to both Solaris and AIX 
machines 
> > > without problems using RSA keys.  Under the DOS console and cygwin's RXVT 
it 
> > > works as expected.
> > >
> > > Starting an `M-x shell' and then invoking ssh within the comint buffer to 
a 
> > > Solaris machine works great.  Tramp using the sshx method to the Solaris 
box 
> > > works as well.
> > >
> > > Doing the same with the AIX box however is problematic.  Under comint, 
the 
> > > response is so slow that it is unusable.  For example, more than a minute 
to 
> > > `ls' an empty directory and get the next prompt.  The output does not 
come 
> > > slowly, but rather all appears at the end of a long wait.  
> > 
> > Does setting process-adaptive-read-buffering to nil help?
> > 
> 
> Nope.  Same behavior
> 
> > >                                                            Tramp using 
sshx is 
> > > unusable because it times out.  In fact, under Emacs, any interaction 
with the 
> > > AIX box exhibits this behavior.  
> > 
> > Is Emacs non-responsive when this happens, or using a lot of CPU?
> > 
> 
> No, Emacs is still responsive; cursor is blinking, no CPU usage.
> 
> > Can you use a debugger to see what emacs is doing when it is waiting for
> > output from the AIX box?
> > 
> > You may have to interrupt the execution several times and make a backtrace
> > to see if there is a specific point where emacs is stuck.
> > 
> 
> I'm building a debug version now.  I'll report my findings once I can test.
> 

Well, I'm not seeing much of note.  I've got a debug version of Emacs running 
under GDB.  I set a breakpoint on Fsignal and am using C-g to get control in 
GDB (if I should be doing this in another way, please let me know...)

In Shell mode waiting for a DOS command to complete:

Breakpoint 3, Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
1606      register struct handler *allhandlers = handlerlist;
(gdb) bt
#0  Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
#1  0x01025552 in Ffuncall (nargs=3, args=0x82f7c0) at eval.c:2907
#2  0x0115a9b4 in Fbyte_code (bytestr=19151275, vector=19151332, maxdepth=24)
    at bytecode.c:694
#3  0x01025ca7 in funcall_lambda (fun=19151244, nargs=0, arg_vector=0x82f9d4)
    at eval.c:3091
#4  0x010256e6 in Ffuncall (nargs=1, args=0x82f9d0) at eval.c:2950
#5  0x01024ffd in apply1 (fn=24203081, arg=23693313) at eval.c:2649
#6  0x01157f90 in Fcall_interactively (function=24203081, 
    record_flag=23693313, keys=23752708) at callint.c:412
#7  0x010151dd in Fcommand_execute (cmd=24203081, record_flag=23693313, 
    keys=23693313, special=23693313) at keyboard.c:9759
#8  0x01008c1e in command_loop_1 () at keyboard.c:1791
#9  0x010230fc in internal_condition_case (bfun=0x10078b4 <command_loop_1>, 
    handlers=23757449, hfun=0x1007330 <cmd_error>) at eval.c:1476
#10 0x0100763a in command_loop_2 () at keyboard.c:1328
#11 0x01022b56 in internal_catch (tag=23751705, 
    func=0x100761b <command_loop_2>, arg=23693313) at eval.c:1214
#12 0x010075ed in command_loop () at keyboard.c:1307
#13 0x01007101 in recursive_edit_1 () at keyboard.c:1000
#14 0x01007237 in Frecursive_edit () at keyboard.c:1061
#15 0x01003a8b in main (argc=2, argv=0xf441e8) at emacs.c:1794

---Type <return> to continue, or q <return> to quit---
Lisp Backtrace:
"signal" (0x16a82a1)
"keyboard-quit" (0x1698801)
"call-interactively" (0x1714f49)
(gdb)

I then connect to the remote machine using CYGWIN's ssh and do a "ls".  While 
waiting for the results to appear, I C-g and get a backtrace.  I continue and 
still have to wait for the remote output.

Breakpoint 3, Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
1606      register struct handler *allhandlers = handlerlist;
(gdb) bt
#0  Fsignal (error_symbol=23757473, data=23693313) at eval.c:1606
#1  0x01025552 in Ffuncall (nargs=3, args=0x82f7c0) at eval.c:2907
#2  0x0115a9b4 in Fbyte_code (bytestr=19151275, vector=19151332, maxdepth=24)
    at bytecode.c:694
#3  0x01025ca7 in funcall_lambda (fun=19151244, nargs=0, arg_vector=0x82f9d4)
    at eval.c:3091
#4  0x010256e6 in Ffuncall (nargs=1, args=0x82f9d0) at eval.c:2950
#5  0x01024ffd in apply1 (fn=24203081, arg=23693313) at eval.c:2649
#6  0x01157f90 in Fcall_interactively (function=24203081, 
    record_flag=23693313, keys=23752708) at callint.c:412
#7  0x010151dd in Fcommand_execute (cmd=24203081, record_flag=23693313, 
    keys=23693313, special=23693313) at keyboard.c:9759
#8  0x01008c1e in command_loop_1 () at keyboard.c:1791
#9  0x010230fc in internal_condition_case (bfun=0x10078b4 <command_loop_1>, 
    handlers=23757449, hfun=0x1007330 <cmd_error>) at eval.c:1476
#10 0x0100763a in command_loop_2 () at keyboard.c:1328
#11 0x01022b56 in internal_catch (tag=23751705, 
    func=0x100761b <command_loop_2>, arg=23693313) at eval.c:1214
#12 0x010075ed in command_loop () at keyboard.c:1307
#13 0x01007101 in recursive_edit_1 () at keyboard.c:1000
#14 0x01007237 in Frecursive_edit () at keyboard.c:1061
#15 0x01003a8b in main (argc=2, argv=0xf441e8) at emacs.c:1794

---Type <return> to continue, or q <return> to quit---
Lisp Backtrace:
"signal" (0x16a82a1)
"keyboard-quit" (0x1698801)
"call-interactively" (0x1714f49)
(gdb) c
Continuing.

Does this help?  Any ideas?  Anything else I should be doing?

Thanks.

  reply	other threads:[~2006-07-03 18:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-27 23:48 W32 to AIX performance Michael Mauger
2006-06-28  8:28 ` Kim F. Storm
2006-06-29  3:10   ` Michael Mauger
2006-07-03 18:11     ` Michael Mauger [this message]
2006-07-03 21:44       ` Kim F. Storm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20060703T195504-934@post.gmane.org \
    --to=mmaug@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).