Date: Wed, 21 Jul 1999 21:25:07 +1000 From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> To: will@iki.fi Cc: hackers@FreeBSD.ORG Subject: Re: speed of file(1) Message-ID: <99Jul21.210648est.40326@border.alcanet.com.au> In-Reply-To: <86u2qy2utc.fsf@not.demophon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Ville-Pertti Keinonen <will@iki.fi> wrote:
>jeremyp@gsmx07.alcatel.com.au (Peter Jeremy) writes:
>> I can't believe these figures.
Based on the figures below, maybe I was overly hasty in this statement.
The changes between 2.x and 3.x magic files have far more impact than
I would have expected.
>What are your results, then?
All timings with everything cached (although the 386 only has 8MB
which limits the cacheability). For the 2.2.5 systems, I give timings
with both the 2.2.5 magic and the 4.0 magic (which is the same as
3.2-RELEASE, in /tmp).
i386SX-25 running 2.2.5 (roughly as posted earlier):
% /usr/bin/time file src/Z/dhcp-2.0b1pl26.tar.gz
src/Z/dhcp-2.0b1pl26.tar.gz: gzip compressed data, deflated, last modified: Thu Jan 1 10:00:00 1970, os: Unix
2.82 real 1.92 user 0.84 sys
% /usr/bin/time file -m /tmp/magic src/Z/dhcp-2.0b1pl26.tar.gz
src/Z/dhcp-2.0b1pl26.tar.gz: gzip compressed data, deflated, last modified: Thu Jan 1 10:00:00 1970, os: Unix
4.05 real 2.67 user 1.23 sys
486DX2-50 running 2.2.5:
% /usr/bin/time file src/Z/dhcp-3.0-alpha-19990423.tar.gz
src/Z/dhcp-3.0-alpha-19990423.tar.gz: gzip compressed data, deflated, last modified: Thu Jan 1 10:00:00 1970, os: Unix
1.43 real 0.96 user 0.38 sys
% /usr/bin/time file -m /tmp/magic src/Z/dhcp-3.0-alpha-19990423.tar.gz
src/Z/dhcp-3.0-alpha-19990423.tar.gz: gzip compressed data, deflated, last modified: Thu Jan 1 10:00:00 1970, os: Unix
2.15 real 1.62 user 0.44 sys
PII-266 running 4.0-CURRENT:
% /usr/bin/time file src/Z/dhcp-1.4.0p6.tar.gz
src/Z/dhcp-1.4.0p6.tar.gz: gzip compressed data, deflated, last modified: Wed Mar 3 20:57:52 1999, os: Unix
0.13 real 0.09 user 0.03 sys
When I profile file in a slow system (like a 386 or 486), there is an
obvious performance bottleneck: The problem is the memcpy() invoked
from fgets(). The only solution would seem to be to mmap() magic
and parse it, rather than using fgets() to read it. This bottleneck
will also be far more obvious on bandwidth-starved systems (like
386SX and 486DX2/4), whereas virtually the whole thing fits into the
L2 cache on my P-II.
Peter
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Jul21.210648est.40326>