Fix dwarfdump stdout handling #282
Conversation
…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
|
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? |
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.
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. |
|
That's a pretty convincing argument! |
|
This is fine. Note that stdout does use Is it worth giving dwarfdump its own crate (while keeping it in this repo)? |
See commit message. This more than doubles dwarfdump output speed on my optimized build of Firefox
libxul.so.