emacs-devel
[Top][All Lists]
Advanced

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

Re: W32 to AIX performance


From: Michael Mauger
Subject: Re: W32 to AIX performance
Date: Mon, 3 Jul 2006 18:11:59 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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 via email to

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