Re: [RFA/testsuite] Significantly speed up commands.exp

Re: [RFA/testsuite] Significantly speed up commands.exp

[Michael Elizabeth Chastain]

Fernando Nasser writes:
> So lets go ahead and remove the hack.
> Thank you very much.

My test bed gives it ten configurations up.  Test suite time drops from
636 seconds to 528 seconds for a typical configuration.  Note that I
use dejagnu 1.4.2, expect 5.33, tcl 8.34.

Works for me,

Michael C

> 2002-04-02  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * lib/gdb.exp (gdb_test): Move -notransfer inside of gdb_expect.
>         (gdb_expect): Remove $notransfer hack.

Re: [RFA/testsuite] Significantly speed up commands.exp

[Fernando Nasser]

Michael Elizabeth Chastain wrote:
> 
> Fernando Nasser writes:
> > So lets go ahead and remove the hack.
> > Thank you very much.
> 
> My test bed gives it ten configurations up.  Test suite time drops from
> 636 seconds to 528 seconds for a typical configuration.  Note that I
> use dejagnu 1.4.2, expect 5.33, tcl 8.34.
> 
> Works for me,
> 
> Michael C
> 

Thanks for verifying it Michael.

Cheers,
Fernando

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFA/testsuite] Significantly speed up commands.exp

[Daniel Jacobowitz]

On Wed, Apr 03, 2002 at 09:18:59AM -0500, Fernando Nasser wrote:
> This apparently was a problem with HP-UX.  Anyway, we should not
> have to hack GDB  -- HP-UX folks have to get a newer Dejagnu if 
> they have not done so yet.
> 
> So lets go ahead and remove the hack.
> 
> Thank you very much.

Thanks, it's in.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA/testsuite] Significantly speed up commands.exp

[Fernando Nasser]

This apparently was a problem with HP-UX.  Anyway, we should not
have to hack GDB  -- HP-UX folks have to get a newer Dejagnu if 
they have not done so yet.

So lets go ahead and remove the hack.

Thank you very much.

Fernando



Daniel Jacobowitz wrote:
> 
> There's no good reason for how long commands.exp takes on any fast machine.
> I figured something was timing out somewhere and went digging.  Sure enough,
> there's a nasty hack in gdb_expect to support -notransfer as the first
> argument to gdb_expect and pass it on to remote_expect in the same way; but
> the comment alludes to a DejaGNU bug which seems to be long gone.  At least,
> I couldn't find it in any version of DejaGNU I looked at.  Similarly, since
> 1994 at least and probably earlier, expect has wanted -notransfer before the
> individual -re entries, not before the whole block.
> 
> Killing the hack saves about a minute in timeouts; every line of a
> multi-line command was pausing for two seconds.  This makes my 4-way test
> runs a little happier.  I think there's another culprit somewhere, but
> before this patch:
> 
> real    23m38.255s
> user    8m22.000s
> sys     1m44.880s
> 
> Afterwards, it should be about 19min.  Wall clock twice system time used
> isn't too shabby, since there's a lot of I/O involved.
> 
> OK to commit?
> 
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
> 
> 2002-04-02  Daniel Jacobowitz  <drow@mvista.com>
> 
>         * lib/gdb.exp (gdb_test): Move -notransfer inside of gdb_expect.
>         (gdb_expect): Remove $notransfer hack.
> 
> Index: gdb.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
> retrieving revision 1.14
> diff -u -p -r1.14 gdb.exp
> --- gdb/gdb/testsuite/lib/gdb.exp       2001/10/02 19:42:10     1.14
> +++ gdb/gdb/testsuite/lib/gdb.exp       2002/04/03 06:14:12
> @@ -440,9 +440,9 @@ proc gdb_test { args } {
>                 # we need to set -notransfer expect option so that
>                 # command output is not lost for pattern matching
>                 # - guo
> -               gdb_expect -notransfer 2 {
> -                   -re "\[\r\n\]" { }
> -                   timeout { }
> +               gdb_expect 2 {
> +                   -notransfer -re "\[\r\n\]" { verbose "partial: match" 3 }
> +                   timeout { verbose "partial: timeout" 3 }
>                 }
>                 set string [string range "$string" [expr $foo + 1] end];
>             } else {
> @@ -1132,20 +1132,6 @@ proc send_gdb { string } {
>  #
> 
>  proc gdb_expect { args } {
> -    # allow -notransfer expect flag specification,
> -    # used by gdb_test routine for multi-line commands.
> -    # packed with gtimeout when fed to remote_expect routine,
> -    # which is a hack but due to what looks like a res and orig
> -    # parsing problem in remote_expect routine (dejagnu/lib/remote.exp):
> -    # what's fed into res is not removed from orig.
> -    # - guo
> -    if { [lindex $args 0] == "-notransfer" } {
> -       set notransfer -notransfer;
> -       set args [lrange $args 1 end];
> -    } else {
> -       set notransfer "";
> -    }
> -
>      if { [llength $args] == 2  && [lindex $args 0] != "-re" } {
>         set gtimeout [lindex $args 0];
>         set expcode [list [lindex $args 1]];
> @@ -1186,7 +1172,7 @@ proc gdb_expect { args } {
>         }
>      }
>      set code [catch \
> -       {uplevel remote_expect host "$gtimeout $notransfer" $expcode} string];
> +       {uplevel remote_expect host $gtimeout $expcode} string];
>      if [info exists old_val] {
>         set remote_suppress_flag $old_val;
>      } else {

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

[RFA/testsuite] Significantly speed up commands.exp

[Daniel Jacobowitz]

There's no good reason for how long commands.exp takes on any fast machine. 
I figured something was timing out somewhere and went digging.  Sure enough,
there's a nasty hack in gdb_expect to support -notransfer as the first
argument to gdb_expect and pass it on to remote_expect in the same way; but
the comment alludes to a DejaGNU bug which seems to be long gone.  At least,
I couldn't find it in any version of DejaGNU I looked at.  Similarly, since
1994 at least and probably earlier, expect has wanted -notransfer before the
individual -re entries, not before the whole block.

Killing the hack saves about a minute in timeouts; every line of a
multi-line command was pausing for two seconds.  This makes my 4-way test
runs a little happier.  I think there's another culprit somewhere, but
before this patch:

real    23m38.255s
user    8m22.000s
sys     1m44.880s

Afterwards, it should be about 19min.  Wall clock twice system time used
isn't too shabby, since there's a lot of I/O involved.

OK to commit?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2002-04-02  Daniel Jacobowitz  <drow@mvista.com>

	* lib/gdb.exp (gdb_test): Move -notransfer inside of gdb_expect.
	(gdb_expect): Remove $notransfer hack.

Index: gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.14
diff -u -p -r1.14 gdb.exp
--- gdb/gdb/testsuite/lib/gdb.exp	2001/10/02 19:42:10	1.14
+++ gdb/gdb/testsuite/lib/gdb.exp	2002/04/03 06:14:12
@@ -440,9 +440,9 @@ proc gdb_test { args } {
 		# we need to set -notransfer expect option so that
 		# command output is not lost for pattern matching
 		# - guo
-		gdb_expect -notransfer 2 {
-		    -re "\[\r\n\]" { }
-		    timeout { }
+		gdb_expect 2 {
+		    -notransfer -re "\[\r\n\]" { verbose "partial: match" 3 }
+		    timeout { verbose "partial: timeout" 3 }
 		}
 		set string [string range "$string" [expr $foo + 1] end];
 	    } else {
@@ -1132,20 +1132,6 @@ proc send_gdb { string } {
 #
 
 proc gdb_expect { args } {
-    # allow -notransfer expect flag specification,
-    # used by gdb_test routine for multi-line commands.
-    # packed with gtimeout when fed to remote_expect routine,
-    # which is a hack but due to what looks like a res and orig
-    # parsing problem in remote_expect routine (dejagnu/lib/remote.exp):
-    # what's fed into res is not removed from orig.
-    # - guo
-    if { [lindex $args 0] == "-notransfer" } {
-	set notransfer -notransfer;
-	set args [lrange $args 1 end];
-    } else {
-	set notransfer "";
-    }
-
     if { [llength $args] == 2  && [lindex $args 0] != "-re" } {
 	set gtimeout [lindex $args 0];
 	set expcode [list [lindex $args 1]];
@@ -1186,7 +1172,7 @@ proc gdb_expect { args } {
 	}
     }
     set code [catch \
-	{uplevel remote_expect host "$gtimeout $notransfer" $expcode} string];
+	{uplevel remote_expect host $gtimeout $expcode} string];
     if [info exists old_val] {
 	set remote_suppress_flag $old_val;
     } else {