Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance differences between spawn() and spawn_bash() #93

Open
ACenTe25 opened this issue Jan 24, 2023 · 2 comments
Open

Performance differences between spawn() and spawn_bash() #93

ACenTe25 opened this issue Jan 24, 2023 · 2 comments

Comments

@ACenTe25
Copy link

ACenTe25 commented Jan 24, 2023

Hello, this is perhaps not an issue, but I've been experimenting with the crate and notice the following behavior:

If I get a PtyReplSession with spawn_bash(Some(timeout)), and then use p.execute(command, ready), the time it takes for this to successfully return is directly related to timeout regardless of the time it actually takes command to reach ready. The higher the timeout, the longer it takes (but it returns Ok), and viceversa (though at a certain point, very small timeouts will fail to find ready).

If I get a PtySession with spawn(command, Some(timeout)), and then use p.exp_string(ready), the time it takes for this to successfully return is independent of timeout. I can change timeout as much as I want (as long as I don't make it too small), and the time to successfully return will remain constant. If ready is not found, the timeout works as expected.

I wouldn't expect the execution time of command to change when running in a PtySession vs a PtyReplSession. Could you explain why this happens? Is it a bug or am I missing something?

Example code with PtyReplSession:

let mut bash_session = spawn_bash(Some(10000))
.expect("session failed");

bash_session.execute("hostname", "mypc")
.expect("command failed");

Example code with PtySession:

let mut session = spawn("hostname", Some(10000))
.expect("session failed");

session.exp_string("mypc")
.expect("command failed");

Here are some test results:

Test: PtyReplSession with 2,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_repl_session_timeout_2000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 2.42s

Test: PtyReplSession with 10,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_repl_session_timeout_10000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 10.45s

Test: PtySession with 2,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_session_timeout_2000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.19s

Test: PtySession with 10,000ms timeout:

running 1 test
test pruebas_rexpect::with_pty_session_timeout_10000 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.16s
@petreeftime
Copy link
Collaborator

spawn_bash waits for bash to exit, which is always timeout unless bash exits or the stream is otherwise interrupted.
spawn will terminate immediately after the command that it executes finishes.

Basically, PtyReplSession is supposed to be interactive, waiting for additional input and providing the output. I think that timeout should rather be set on the execute function instead, since it would track the execution of the particular command, not of the session.

@ACenTe25
Copy link
Author

Yes, I agree with setting the timeout on the execute function, however if PtyReplSession is intended just for interactive use, then the "correct" session for automation/non-interactive use would always be PtySession, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants