Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!giza.cis.ohio-state.edu!jgreely
From: jgreely@giza.cis.ohio-state.edu (J Greely)
Newsgroups: alt.sources.d
Subject: Re: promoting Perl (was Re: uutraffic report (in perl))
Message-ID: <JGREELY.89Nov29122605@giza.cis.ohio-state.edu>
Date: 29 Nov 89 17:26:05 GMT
References: <4025@mhres.mh.nl> <1194@radius.UUCP> <3273@convex.UUCP>
	<5261@omepd.UUCP> <1126@cirrusl.UUCP> <1989Nov28.064349.1421@eda.com>
	<411@jhereg.Minnetech.MN.ORG>
Sender: news@tut.cis.ohio-state.edu
Reply-To: J Greely <jgreely@cis.ohio-state.edu>
Organization: Ohio State University Computer and Information Science
Lines: 26
In-reply-to: mark@jhereg.Minnetech.MN.ORG's message of 28 Nov 89 16:35:11 GMT

In article <411@jhereg.Minnetech.MN.ORG> mark@jhereg.Minnetech.MN.ORG (Mark H. Colburn) writes:
>	find <path> <pattern> -print | xargs <any command>
>I would venture to say that the xargs version may actually be faster than
>the perl version.

Well, a quick test on a smallish (~200K) directory tree says that
xargs doesn't always win.

	find . -type f -print | xargs rm -f
vs.
	find . -type f -print | perl -ne 'chop;unlink;'

Perl came out about 25% faster in this particular case.  I believe the
biggest problem with xargs is sub-optimal buffering.


  Now, if everyone would stop mentioning xargs as the "obvious"
solution, we'll all be happier.  One, it's not always the most
efficient.  Two, it's not universally supplied (not on *my* BSD 4.3
tape).  Three, the whatis line for xargs doesn't jump out at a novice
user.  It *might* be clear enough for some, but it might not.

	  xargs	- construct argument list(s) and execute command

--
J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)


Brought to you by Super Global Mega Corp .com