bin/86485: [patch] hexdump(1): hexdump -s speedup on /dev

Alexander Best alexbestms at
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>
To: <bug-followup at>
Cc: Garrett Cooper <yaneurabeya at>,
 Toby Peterson <toby at>
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
 4,938 total
 time ./hexdump -n 2 -s 999999999 /dev/zero  0,00s user 0,00s system 89% cpu
 0,005 total
 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
 "if (S_ISREG(sb.st_mode))"
 statement should stay. removing it causes the warning i got during
 benchmarking, because fseeko() itself outputs a warning if it's being run o=
 n a
 non-seekable file.
 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=
 f 1
 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 mailing list