Bug #53672 for File-Find-Rule: SYNOPSIS pod is horribly unoptimised

Wed Jan 13 23:54:46 2010 adamk [...] cpan.org - Ticket created

Subject:

SYNOPSIS pod is horribly unoptimised

The File::Find::Rule documentation currently encourages the use of the FFR API in a resource-wasteful manner. # find all the .pm files in @INC my @files = File::Find::Rule->file() ->name( '*.pm' ) ->in( @INC ); This example may read well, but it encourages the use of a highly expensive filesystem test before a relatively cheap name test. I would recommend that the ordering of the methods be reversed to have the use of the name pattern BEFORE the filesystem test. Even better would be if File::Find::Rule could automatically optimise itself by reordering order-irrelevant conditions so that the ->name was automatically moved to be before the ->file in all situations it was desirable. But that's another ticket. In the mean time, encouraging name tests before filesystem tests should result in making many recursive-scanning applications significantly faster.

Mon Jan 18 11:09:31 2010 richardc [...] unixbeard.net - Correspondence added

CC:	undisclosed-recipients: ;
Subject:	Re: [rt.cpan.org #53672] SYNOPSIS pod is horribly unoptimised
Date:	Mon, 18 Jan 2010 16:09:12 +0000
To:	Adam Kennedy via RT <bug-File-Find-Rule [...] rt.cpan.org>
From:	Richard Clamp <richardc [...] unixbeard.net>

On Wed, Jan 13, 2010 at 11:54:47PM -0500, Adam Kennedy via RT wrote: Show quoted text

> Even better would be if File::Find::Rule could automatically optimise > itself by reordering order-irrelevant conditions so that the ->name was > automatically moved to be before the ->file in all situations it was > desirable.

There are a couple of cases when silently reordering subrules break the intent of the rule, and as such make it a fairly interesting problem to look at. I did a fairly naiive implementation by assigning a 'cost' to each subrule, and sorting so long as there are no uncosted subrules like the thorny 'discard'. http://github.com/richardc/perl-file-find-rule/commits/cost Not sure if that's worth kicking about some more, or trying another approach. Show quoted text

> But that's another ticket. In the mean time, encouraging name tests > before filesystem tests should result in making many recursive-scanning > applications significantly faster.

I'm aware there's a certain amount of monkey-see monkey-do which afflicts programmers, which tweaking the SYNOPSIS might fix, but what it needs is a really good paragraph or two to peek behind the curtain and remind people what they're getting is high level syntax around ' -f $_ && $_ =~ /^foo\..*/ ' and to adjust accordingly. So far I've been unable to phrase that in a way that's sufficiently one-size-fits-all for the module documentation that doesn't confuse or become immediately untrue. -- Richard Clamp <richardc@unixbeard.net>

Mon Jan 18 11:09:32 2010 The RT System itself - Status changed from 'new' to 'open'

Wed Jan 20 04:43:54 2010 adam [...] ali.as - Correspondence added

CC:	adamk [...] cpan.org
Subject:	Re: [rt.cpan.org #53672] SYNOPSIS pod is horribly unoptimised
Date:	Wed, 20 Jan 2010 20:42:05 +1100
To:	bug-File-Find-Rule [...] rt.cpan.org
From:	Adam Kennedy <adamkennedybackup [...] gmail.com>

I understand your problems, I'm trying to implement something similar inside of Aspect.pm atm. I still think it's worth doing the simplest stuff for the monkey see monkey do though, since that is the entire reason the SYNOPSIS exists (to cater to that crowd) Adam K 2010/1/19 richardc@unixbeard.net via RT <bug-File-Find-Rule@rt.cpan.org>: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=53672 > > > On Wed, Jan 13, 2010 at 11:54:47PM -0500, Adam Kennedy via RT wrote:

>> Even better would be if File::Find::Rule could automatically optimise >> itself by reordering order-irrelevant conditions so that the ->name was >> automatically moved to be before the ->file in all situations it was >> desirable.

> > There are a couple of cases when silently reordering subrules > break the intent of the rule, and as such make it a fairly interesting > problem to look at. I did a fairly naiive implementation by assigning a > 'cost' to each subrule, and sorting so long as there are no uncosted > subrules like the thorny 'discard'. > > http://github.com/richardc/perl-file-find-rule/commits/cost > > Not sure if that's worth kicking about some more, or trying another > approach. >

>> But that's another ticket. In the mean time, encouraging name tests >> before filesystem tests should result in making many recursive-scanning >> applications significantly faster.

> > > I'm aware there's a certain amount of monkey-see monkey-do which > afflicts programmers, which tweaking the SYNOPSIS might fix, but what it > needs is a really good paragraph or two to peek behind the > curtain and remind people what they're getting is high level > syntax around ' -f $_ && $_ =~ /^foo\..*/ ' and to adjust > accordingly. > > So far I've been unable to phrase that in a way that's sufficiently > one-size-fits-all for the module documentation that doesn't confuse > or become immediately untrue. > > > -- > Richard Clamp <richardc@unixbeard.net> > >