Skip to content

Conversation

@Geun-Oh
Copy link

@Geun-Oh Geun-Oh commented Oct 25, 2025

Hello team.

This PR Closes #2220

I've changed response writing logic without dump option to write down stdout directly without copying and converting types.

Now there are no dramatic timp delay between the two operations.

time cargo run --bin quiche-client -- \
https://127.0.0.1:4433/1GB.bin --no-verify
   Compiling quiche_apps v0.1.0 (/Users/ohyeong-geun/rust/quiche/apps)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.57s
     Running `target/debug/quiche-client 'https://127.0.0.1:4433/1GB.bin' --no-verify`
cargo run --bin quiche-client -- https://127.0.0.1:4433/1GB.bin --no-verify  0.15s user 0.07s system 21% cpu 0.993 total
time cargo run --bin quiche-client -- \
https://127.0.0.1:4433/1GB.bin --no-verify \
--dump-responses /tmp
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/quiche-client 'https://127.0.0.1:4433/1GB.bin' --no-verify --dump-responses /tmp`
cargo run --bin quiche-client -- https://127.0.0.1:4433/1GB.bin --no-verify    0.15s user 0.06s system 41% cpu 0.489 total

Additionally, I've used BufWriter to minimize system calls (If we use ``std::io::stdout().write_all()`, there might be a x8 syscalls).

Please check and leave any comments.

Thanks.

@Geun-Oh Geun-Oh requested a review from a team as a code owner October 25, 2025 13:14
buf[..read].to_vec(),
)
});
self.stdout_writer.write_all(&buf[..read]).ok();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without the from_utf8_unchecked() then we risk binary being printed to stdout, which can cause terminal corruption

Copy link
Author

@Geun-Oh Geun-Oh Oct 28, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your right.
And I found that it seems normal to take time when calling large file. I need to check real issue situation and debug it again.

I've asked the one who issued this to provide reproducible example.

@Geun-Oh
Copy link
Author

Geun-Oh commented Oct 28, 2025

Hello @YoussefBaccouch .

I've been working with this issue (the one that you asked in #2200) and debugging all the internal logics.
But I discovered that when I call massive file from server, it takes pretty long time and there are no differences between --dump-responses argument usage.

I think it seems normal that it takes time to call massive files.
So can you just give me a reproducible example that I can debug real problem?

Thanks :)

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

Successfully merging this pull request may close these issues.

Fix time consuming error without --dump-response argument

2 participants