[33102] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4378 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Feb 24 05:17:19 2015

Date: Tue, 24 Feb 2015 02:17:04 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Tue, 24 Feb 2015     Volume: 11 Number: 4378

Today's topics:
    Re: Traversing through sub dirs and read file contents (Tim McDaniel)
    Re: Traversing through sub dirs and read file contents (Tim McDaniel)
    Re: Traversing through sub dirs and read file contents <m@rtij.nl.invlalid>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Mon, 23 Feb 2015 16:25:30 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <mcfk9q$2sj$1@reader1.panix.com>

In article <pmprrb-umh.ln1@news.rtij.nl>,
Martijn Lievaart  <m@rtij.nl.invlalid> wrote:
>On Sun, 22 Feb 2015 18:34:46 +0000, Tim McDaniel wrote:
>
>> In article <fu5tqb-3lm.ln1@news.rtij.nl>,
>> Martijn Lievaart  <m@rtij.nl.invlalid> wrote:
>>>On Wed, 11 Feb 2015 21:58:47 +0100, Peter J. Holzer wrote:
>>>
>>>> That depends on what the OP means by "a lot of files". Hundreds?
>>>> Thousands? Tens of thousands? Millions? Billions? Probably hundreds or
>>>> thousands. And it probably doesn't matter unless we get into at least
>>>> the 100k to 1M files per directory range, possibly even higher.
>>>
>>>As a side note, current file systems may handle that many files in a
>>>directory gracefully, but maybe not.
>> 
>> Exemplia gratia: I *very occasionally* run P4V, a GUI front-end for
>> Perforce. [1]  The problems:
>> - the one thing that isn't fast is the network latency
>> - one of the
>> directories has a bazillion directories and files, and is
>>   the parent of most of the source tree
>
>Sorry, but this falls in the category "Don't do that then!"

I notice how you deleted my next line,
>> None of which I have the slightest control over.
in which I was trying to tell people not to lecture me about the
blatantly obvious problems and blatantly obvious solutions that
I cannot effect at all.

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Mon, 23 Feb 2015 16:31:35 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <mcfkl7$ad9$1@reader1.panix.com>

In article <0btrrb-umh.ln1@news.rtij.nl>,
Martijn Lievaart  <m@rtij.nl.invlalid> wrote:
>On Mon, 23 Feb 2015 15:02:02 +0000, Rainer Weikusat wrote:
>> All of this amounts to nothing but 'change the environment such
>> that assumptions coded into the software are less wrong'.
>
>No. Even if the software behaviour is slightly moronic, there is not
>much P4V can do about a pathetic setup. Doing a ls will trigger the
>same behaviour.

No, actually, it doesn't.  A dir on expoderdir takes 5 seconds, so I
think it's actually Perforce much more than the filesystem.  P4V could
have been coded not to expand directories unless requested.  P4V could
have been coded not to be single threaded so it could do several
things at once, including the thing I want it to do, rather than "(Not
responding)" for 20 minutes ...

and why am I wasting time with discussing things that are completely
out of my control?

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Mon, 23 Feb 2015 17:44:52 +0100
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Traversing through sub dirs and read file contents
Message-Id: <412srb-umh.ln1@news.rtij.nl>

On Mon, 23 Feb 2015 16:31:35 +0000, Tim McDaniel wrote:

> In article <0btrrb-umh.ln1@news.rtij.nl>,
> Martijn Lievaart  <m@rtij.nl.invlalid> wrote:
>>On Mon, 23 Feb 2015 15:02:02 +0000, Rainer Weikusat wrote:
>>> All of this amounts to nothing but 'change the environment such that
>>> assumptions coded into the software are less wrong'.
>>
>>No. Even if the software behaviour is slightly moronic, there is not
>>much P4V can do about a pathetic setup. Doing a ls will trigger the same
>>behaviour.
> 
> No, actually, it doesn't.  A dir on expoderdir takes 5 seconds, so I
> think it's actually Perforce much more than the filesystem.  P4V could
> have been coded not to expand directories unless requested.  P4V could
> have been coded not to be single threaded so it could do several things
> at once, including the thing I want it to do, rather than "(Not
> responding)" for 20 minutes ...
> 
> and why am I wasting time with discussing things that are completely out
> of my control?

I stand corrected.

M4


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 4378
***************************************


home help back first fref pref prev next nref lref last post