Front page | perl.perl5.porters |
Postings from September 2010
Re: Remove Devel::DProf from 5.16
From: Nicholas Clark
September 2, 2010 02:34
Re: Remove Devel::DProf from 5.16
Message ID: 20100902093418.GC48531@plum.flirble.org
On Thu, Aug 19, 2010 at 09:16:18AM -1000, tim.jenness wrote:
> On Aug 19, 2010, at 9:13 AM, Nicholas Clark wrote:
> > On Thu, Aug 19, 2010 at 09:10:04AM -1000, tim.jenness wrote:
> >> Great idea. Could we rebrand Devel::NYTProf so Devel::DProf would still be the perl profiler? Most people just want -d:DProf to work.
> > Effectively this would eliminate acknowledgment of the contribution of the
> > New York Times back to the Perl ecosystem, which I feel would be unwise.
> Ok. I hadn't fully appreciated why it was called NYTProf...
> I suppose the next question is whether perl should ship with a profiler or not. I'm guessing "not".
I don't see that it *needs* to.
It's not like a profiler is a runtime requirement of production systems.
If a developer isn't able (or capable) of installing a profiler themselves
then it's a technical (or political) problem at their end, and shouldn't be
our responsibility to provide a technical solution for them.
Devel::DProf isn't a huge technical burden sitting there being "special
biologist word". But having it be the "official" profiler, and the profiler
that everyone finds, is "Less Than Awesome", given that there *is* an
awesome profiler out there.
And whilst we *could* *try* to bundle Devel::NYTProf into the core, I don't
think that it would be worth it because
1: It's not part of the (installation) toolchain, or a ubiquitous prerequistite
2: Its development cycle is more rapid than the core's release cycle
3: I remember the pain in getting Storable to build on all the platforms and
configurations that the core built on at that time. Even believed-to-be
portable XS modules turn out not to be when subjected to the core's
smoke testing platforms. CPAN testers typically smoke on only the most
common Configure settings for that OS.
To my mind "rebranding" on its own makes no sense.
If something is called Devel::DProf it *should* support the same interface
On Fri, Aug 20, 2010 at 10:09:38AM -0700, Jan Dubois wrote:
> On Fri, 20 Aug 2010, Tim Bunce wrote:
> > On Thu, Aug 19, 2010 at 08:13:57PM +0100, Nicholas Clark wrote:
> > > On Thu, Aug 19, 2010 at 09:10:04AM -1000, tim.jenness wrote:
> > > >
> > > > Great idea. Could we rebrand Devel::NYTProf so Devel::DProf would
> > > > still be the perl profiler? Most people just want -d:DProf to work.
> > >
> > > Effectively this would eliminate acknowledgment of the contribution of the
> > > New York Times back to the Perl ecosystem, which I feel would be unwise.
> > The New York Times hasn't contributed anything to NYTProf in years.
> > Arguably they're being rewarded for forking a project (Devel::SmallProf)
> > that they could have simply contributed to.
I'd not thought of it that way.
> Yes, but from a Perl advocacy point of view it is nice to be able to say:
> See, Perl is such an integral part of the NYT systems that they went
> all the way of creating a kick-ass profiler for it.
> So even if the NYT didn't care about the attribution anymore (I have no
> idea if they do or don't), it would still be beneficial for the Perl
> world to keep it, IMO.
And I'd not thought of it that way either, and I *like* your style. :-)
On Thu, Aug 19, 2010 at 04:10:18PM -0700, Joshua ben Jore wrote:
> On Thu, Aug 19, 2010 at 11:24 AM, Nicholas Clark <firstname.lastname@example.org> wrote:
> > Devel::DProf is obsolete. For details of why it can't be fixed, see
> > http://blog.timbunce.org/2008/07/12/devel-dprof-broken-by-the-passage-of-time/
> > I propose that we remove it from core by 5.16. I'm not sure whether the
> > better approach is
> > a: package it on CPAN for people who (think that they) "really" need it
> > (can be for 5.14+ only, which eases the backporting issues)
> > or
> > b: just kill it
> b) was how B::CC got killed from core. Reini later picked it up and
> has been doing interesting things with it. I think that was a
> fantastically successful deprecation. DProf could easily die off the
> same way.
B::CC has the potential to be useful in some situations.
I don't believe that anyone has justified the scenarios where Devel::DProf
offers something that can't be done, or can't easily be done, with
And I'm thinking somewhat in the vein of "you have to be cruel to be kind".
By removing the "easy" option of distributors and end users to "just"
checkout from CPAN the >10 year old profiler they were using, we force
them out of their rut, and cause them to have to actually use something
decent. So it's partly a user re-education programme.
[Someone is going to dislike me for thinking like that.]