bin/86485: [patch] hexdump(1): hexdump -s speedup on /dev
alexbestms at wwu.de
Sun Feb 28 16:30:05 UTC 2010
The following reply was made to PR bin/86485; it has been noted by GNATS.
From: Alexander Best <alexbestms at wwu.de>
To: <bug-followup at FreeBSD.org>
Cc: Garrett Cooper <yaneurabeya at gmail.com>,
Toby Peterson <toby at apple.com>
Subject: Re: bin/86485: [patch] hexdump(1): hexdump -s speedup on /dev
Date: Sun, 28 Feb 2010 17:29:51 +0100 (CET)
i can't verify the performance decrease running HEAD (r204383) garrett
mentioned. here are some benchmark (hexdump being the unpatched binary and
=2E/hexdump including toby's patches):
time hexdump -n 2 -s 999999999 /dev/zero 4,45s user 0,43s system 98% cpu
time ./hexdump -n 2 -s 999999999 /dev/zero 0,00s user 0,00s system 89% cpu
however while the unpatched hexdump binary succeeds doing
hexdump -n 2 -s 99999999 /dev/ada0 0,52s user 0,52s system 19% cpu 5,418
the patched binary outputs a warning
hexdump: /dev/ada0: Invalid argument
=2E/hexdump -n 2 -s 99999999 /dev/ada0 0,00s user 0,00s system 89% cpu 0,0=
to me the patch doesn't look right however, because
1. if a file is not seekable, fseeko() shouldn't be used. so the
statement should stay. removing it causes the warning i got during
benchmarking, because fseeko() itself outputs a warning if it's being run o=
2. the real cause for the slowdown on non-seekable files is the use of
getchar() which is testing whether EOF has been reached using a blocksize o=
dd is much faster when dealing with non-seekable files. the difference howe=
is that dd won't accept a seek value which is bigger than the filesize.
hexdump on the other hand will accept any seek value. if it's bigger than t=
filesize it outputs the last byte(s) before the EOF.
the dd code dealing with non-seekable files can be found in
maybe it's possible to use some of it to get rid of getchar().
More information about the freebsd-bugs