Front page | perl.perl5.porters |
Postings from January 2012
Re: whither study()?
Thread Previous
|
Thread Next
From:
Nicholas Clark
Date:
January 31, 2012 08:43
Subject:
Re: whither study()?
Message ID:
20120131164322.GH9069@plum.flirble.org
On Tue, Jan 31, 2012 at 12:31:23AM +0100, demerphq wrote:
> On 31 January 2012 00:19, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
> > * demerphq <demerphq@gmail.com> [2012-01-29T04:41:33]
> >> Is it really in Perls interest that I, or anyone else with the chops,
> >> even looks at fixing the bugs related to it? Can we just no-op and
> >> deprecate it?
> >
> > A few years ago, I casually proposed deprecating it. This was on IRC or at a
> > conference or something. A few people objected that it was actually useful, at
> > least sometimes, so I know it's being used.
>
> Interesting.
But, this is a costly feature that benefits only a few, and by implication
steals maintainer attention from areas that benefit many or all.
Are its advocates able to contribute in any way to its upkeep?
> > Is it being used to any effect, in most cases? Is it introducing problems?
> > Are the breakages that it introduces the only thing keeping code working, now?
> > Hoo boy!
> >
> > If it really is as broken as you say -- and I have no reason (or desire!) to
> > doubt you -- then it does seem worth doing something about.
>
> We /do/ test it, yet it is broken in some subtle ways, and maybe
> worse, its is hard to tell. But it definitely complicates the goo
> around the regex engine.
Which I feel is two arguments for dropping it. If we had infinite resources,
it would be different. But as we have only finite knowledgeable people to
work on the regex engine, doing *some*thing has the implicit trade off of
not doing some *other* thing.
Hence, as is:
1: Fixing study steals time from fixing other bugs, or making other
improvements
2: Merely having study's goo in the regex engine increases the time taken do
do anything else, so it's also costing time just to stand still.
> > Do we really want to deprecate it? Some day, maybe we will want to add this
> > feature back, and someone will have the energy to write a useful implementation
> > and test suite. Unlike many features, where there's some design gain to be
> > made by ditching it, study isn't a wart. It's just a once implemented and now
> > pretty busted thing that might be useful again someday.
>
> Ah I totally agree. I had "no op" in my head much stronger than
> "deprecate". Lets no-op it, and see if anybody files a ticket
> reporting a slowdown. No ticket, no problem. :-) I wonder if we will
> get "bug" reports about peoples patterns starting to match correctly?
> :-)
>
> > The promise of study is that everything will work the same, with some shift in
> > where cost is. What if study became a nop?
>
> Totally agree. It *should* be a noop. Then if we ever do have a use
> for it we can just un-no-op it. (heh)
I think from the the user side, it should be a no-op. Given that the
documentation already warns:
This may or may not save time, depending on the nature and number of
patterns you are searching on, and on the distribution of character
frequencies in the string to be searched; you probably want to compare
run times with and without it to see which runs faster.
and for all stable versions of Perl
You may have only one C<study> active at a time: if you study a different
scalar the first is "unstudied".
it's already covered in caveats that it might not do what you hoped.
As to implementation - right now, I have this niggling feeling that the
best approach *right now*, with 5.16.0 getting close, and Dave's major
reworking unmerged, is just to disable the code in the most minimal way
possible, and not remove anything. (eg make pp_study unconditionally
RETPUSHNO; very early, #if 0/#endif the rest of it)
Do the actual removal of code (from the regex engine, pp.c and util.c -
are there more?) in 5.17.early, after Dave's work is merged, and once we're
reasonably comfortable that we hadn't missed reasons for retaining it.
(Or easy fixes for part of what it does)
But keep the keyword in case in the future it becomes obvious how to use
it cleanly to speed up matching.
Nicholas Clark
Thread Previous
|
Thread Next