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

Fix dwarfdump stdout handling #282

Merged
merged 1 commit into from
Feb 26, 2018
Merged

Fix dwarfdump stdout handling #282

merged 1 commit into from
Feb 26, 2018

Conversation

rocallahan
Copy link
Contributor

See commit message. This more than doubles dwarfdump output speed on my optimized build of Firefox libxul.so.

…r stdout

Before this change, every print(ln) was taking a lock, doing a write syscall,
and releasing the lock.

Before:

time ( target/release/examples/dwarfdump -i ~/mozilla-central/obj-ff-opt/dist/bin/libxul.so >& /dev/null )
real	8m25.647s
user	7m6.523s
sys	1m18.650s

After:

time ( target/release/examples/dwarfdump -i ~/mozilla-central/obj-ff-opt/dist/bin/libxul.so >& /dev/null )
real	3m35.072s
user	3m33.297s
sys	0m1.556s
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.4%) to 92.507% when pulling ae191fd on rocallahan:fast-stdout into 03281b6 on gimli-rs:master.

@fitzgen
Copy link
Member

fitzgen commented Feb 26, 2018

Is the speed up mostly from locking stdout or from increasing buffering from every newline to some larger buffer size?

@philipc do you think it is even worth investing in speed ups for our example dwarfdump?

@rocallahan
Copy link
Contributor Author

Is the speed up mostly from locking stdout or from increasing buffering from every newline to some larger buffer size?

The latter, I believe. The cost of a syscall should greatly exceed the cost of acquiring and releasing an uncontended lock unless something has gone very wrong.

do you think it is even worth investing in speed ups for our example dwarfdump?

When studying the debuginfo for libxul or other large binaries, dwarfdump performance really matters to me. The large size of the output (libxul.so generates 24G of output) means it's impractical to just dump to a file once and repeatedly search that file. I have some additional patches to speed it up using parallelism and filtering.

gimli's dwarfdump may only be an "example" but it's very useful in its own right. objdump/readelf don't support newer DWARF5 stuff and are not especially fast --- with these patches, gimli dwarfdump is slightly faster, and the pending changes I have make gimli dwarfdump much faster. libdwarf's dwarfdump is nasty. I'd rather hack on gimli's dwarfdump than the others since we're using gimli internally, and Rust vs C --- I'd hate to implement the parallelism stuff in C.

If you don't want to take these patches, that's fine; I'll fork dwarfdump for our own use.

@fitzgen
Copy link
Member

fitzgen commented Feb 26, 2018

That's a pretty convincing argument!

@fitzgen fitzgen merged commit 59ea56b into gimli-rs:master Feb 26, 2018
@philipc
Copy link
Collaborator

philipc commented Feb 27, 2018

This is fine. Note that stdout does use LineWriter, so this results in double buffering. I don't think there's any way to avoid that currently though, and the inner buffer will mostly be bypassed since it has a smaller capacity.

Is it worth giving dwarfdump its own crate (while keeping it in this repo)?

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.

4 participants