promoting Perl (was Re: uutraffic report (in perl))

[Jim Budler]

mark at jhereg.Minnetech.MN.ORG (Mark H. Colburn) writes:

} In article <1989Nov28.064349.1421 at eda.com> jim at eda.com (Jim Budler) writes:

} >I can't actually disagree with you, however, perl won me over with
} >ONE simple example:
} >	% find <path> <pattern> -exec < most any command> \;
} >versus
} >	% find <path> <pattern> -print | perl -ne 'equiv_command;'
} >The performance improvement was HUGE!

} The same improvement can be had with:

} 	find <path> <pattern> -print | xargs <any command>

} I would venture to say that the xargs version may actually be faster than
} the perl version.

I doubt it, since it forks a process for each expansion, just like
	% find <path> <pattern> -exec <most any command> \;

Let me give a specific example:

	% find / -name core -exec rm {} \;
will fork rm for each match. This is what makes it slow.
	% find / -name core -print | xargs rm
will also fork rm for each match.

} I'm not trying to bash perl, but check for tools that already exist and use
} them where appropriate.  Perl is a great program for doing data
} manipulation and report processing and stuff, but it is not intended to be
} a panacea for all lifes little problems.  It's not necessarily  the most
} efficient thing out there for pasting command line arguments together and
} feeding them to an arbitrary command, for example.

You missed the actual point of why I said <equiv_command> in the original
post. You cannot feed to arbitrary commands, you feed to perl commands. In
this example instead of rm, the perl command is unlink. Perl will not
fork any process to do the 'rm', it will unlink the file itself. This
is why it is faster than the traditional find command, and your xargs
version.

Additional points:

1. xargs is not universal, although I have a tape with a PD version
somewhere.

2. on deep trees, the command expanded by xargs can exceed the command
line length buffer in either xargs or the shell it forks (not sure which)
and so it fails to produce the desired result.

} -- 
} Mark H. Colburn                       mark at Minnetech.MN.ORG
} Open Systems Architects, Inc.


jim
-- 
Jim Budler	jim at eda.com    ...!{decwrl,uunet}!eda!jim
compuserve: 72415,1200     applelink: D4619
voice: +1 408 986-9585     fax: +1 408 748-1032