Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.perl.misc > #4762

Re: Find the oldest files without using ls -tr

From tmcd@panix.com (Tim McDaniel)
Newsgroups comp.unix.shell, comp.lang.perl.misc
Subject Re: Find the oldest files without using ls -tr
Date 2012-03-15 19:06 +0000
Organization Tim McDaniel's at Panix
Message-ID <jjtek8$slj$1@reader1.panix.com> (permalink)
References <29316929-0f1b-466e-9041-3113bf4fe6c5@i5g2000yqo.googlegroups.com> <0fu839-1k22.ln1@anubis.morrow.me.uk> <jjt2s4$eru$1@reader1.panix.com> <u4j939-2v62.ln1@anubis.morrow.me.uk>

Cross-posted to 2 groups.

Show all headers | View raw


In article <u4j939-2v62.ln1@anubis.morrow.me.uk>,
Ben Morrow  <ben@morrow.me.uk> wrote:
>
>Quoth tmcd@panix.com:
>> In article <0fu839-1k22.ln1@anubis.morrow.me.uk>,
>> Ben Morrow  <ben@morrow.me.uk> wrote:
>> 
>> >it also runs perl in parallel with find rather than waiting.
>> 
>> I don't know of any reason why find couldn't run -exec in parallel,
>
>Think about it. If you're running
>
>    find . -exec perl -e... {} +
>
>then find has to collect up ARG_MAX-worth of filenames before it can
>even try to invoke perl.

I was thinking of the parallelism of find starting, getting ARG_MAX
arguments, invoking perl for the first time, and then without waiting
for that first perl to finish, starts accumulating the arguments for
the second call of perl.

There's then the further design decision about parallelism: if find
gets the arguments for the second call of perl, should it wait for the
first perl to finish before running the second call of perl?  I don't
know what xargs does in such a case. ... Experimentally, in NetBSD,
xargs waits for the first execution to finish before starting the
second.  That's probably a wiser default, considering how one run
of whatever command you run might have a dependency with another run,
or that running several at once might hammer your machine.

With
>
>    find . -print0 | perl -n0 -e...
>
>perl is invoked by the shell at the same time as find, and can (subject
>to buffering) read filenames one at a time as they come in.

The buffering is not negligable, I think, in small cases.

And that's a startup effect: in large cases, the parallelism of find
and perl (in the first sense I defined above) should dominate the
efficiency of this sort of parallelism.  That is, if the perl process
takes longer to run than the find that gets its arguments, the total
time is (startup+time for all perls).  Or, if find instead takes more
time, then it's (startup+time for all finds).

-- 
Tim McDaniel, tmcd@panix.com

Back to comp.lang.perl.misc | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Re: Find the oldest files without using ls -tr Ivan Shmakov <oneingray@gmail.com> - 2012-03-14 22:43 +0700
  Re: Find the oldest files without using ls -tr Ben Morrow <ben@morrow.me.uk> - 2012-03-14 18:05 +0000
    Re: Find the oldest files without using ls -tr Sven Mascheck <mascheck@email.invalid> - 2012-03-14 18:31 +0000
      Re: Find the oldest files without using ls -tr Ben Morrow <ben@morrow.me.uk> - 2012-03-14 19:59 +0000
        Re: Find the oldest files without using ls -tr Janis Papanagnou <janis_papanagnou@hotmail.com> - 2012-03-15 00:16 +0100
          Re: Find the oldest files without using ls -tr Ben Morrow <ben@morrow.me.uk> - 2012-03-15 02:12 +0000
            Re: Find the oldest files without using ls -tr Janis Papanagnou <janis_papanagnou@hotmail.com> - 2012-03-15 09:42 +0100
              Re: Find the oldest files without using ls -tr Ben Morrow <ben@morrow.me.uk> - 2012-03-15 10:56 +0000
                Re: Find the oldest files without using ls -tr tmcd@panix.com (Tim McDaniel) - 2012-03-15 15:46 +0000
                Re: Find the oldest files without using ls -tr Ben Morrow <ben@morrow.me.uk> - 2012-03-15 16:49 +0000
                Re: Find the oldest files without using ls -tr tmcd@panix.com (Tim McDaniel) - 2012-03-15 19:06 +0000
                Re: Find the oldest files without using ls -tr Casper H.S. Dik <Casper.Dik@OrSPaMcle.COM> - 2012-03-15 17:13 +0000

csiph-web