From owner-freebsd-bugs@FreeBSD.ORG Sun Feb 28 16:30:04 2010 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDCE9106566C for ; Sun, 28 Feb 2010 16:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id C3AA08FC1A for ; Sun, 28 Feb 2010 16:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id o1SGU4TT024553 for ; Sun, 28 Feb 2010 16:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id o1SGU4rH024548; Sun, 28 Feb 2010 16:30:04 GMT (envelope-from gnats) Date: Sun, 28 Feb 2010 16:30:04 GMT Message-Id: <201002281630.o1SGU4rH024548@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Alexander Best Cc: Subject: Re: bin/86485: [patch] hexdump(1): hexdump -s speedup on /dev X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alexander Best List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 16:30:05 -0000 The following reply was made to PR bin/86485; it has been noted by GNATS. From: Alexander Best To: Cc: Garrett Cooper , Toby Peterson 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 total the patched binary outputs a warning hexdump: /dev/ada0: Invalid argument 5f5e0ff =2E/hexdump -n 2 -s 99999999 /dev/ada0 0,00s user 0,00s system 89% cpu 0,0= 06 total 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 byte. dd is much faster when dealing with non-seekable files. the difference howe= ver 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= he filesize it outputs the last byte(s) before the EOF. the dd code dealing with non-seekable files can be found in /usr/src/bin/dd/position.c:pos_in() maybe it's possible to use some of it to get rid of getchar(). cheers. alex