J David Blackstone <[EMAIL PROTECTED]> writes:
> I think the success criteria on http://dev.perl.org/pm/pos.html
> should be more measurable.
>> SUCCESS CRITERIA
>> 1. Benchmarks of text processing programs show improved performance on
> perl6 over perl5.
> Yes, but how much improved? Is 50% in everyone's minds, or is 10%
> enough? How much improvement is feasible?
Speaking just for me, I find Perl mostly acceptably fast, but it would be
nice to get back to the speed of earlier Perl 5 releases; from what I
remember, we've been going downhill in this department for a little while
as more features have been added. And we want to add several things, such
as threading, a more easily-maintained core, and full Unicode support that
risk slowdowns unless attended to with great care.
>> 5. The internals API is simpler than in perl5.
> I have no suggestions on how to measure this. I think it needs to say
> more, though. I haven't been following -internals, but I'd like to hear
> some of their feedback on how much simpler it's going to get.
I just want to not have to write:
if (!body) {
body = newSV(0);
(void) SvUPGRADE(body, SVt_PV);
}
SvPVX(body) = artBody;
SvCUR_set(body, strlen(artBody));
SvLEN_set(body, 0);
SvPOK_on(body);
(void) SvREADONLY_on(body);
(void) SvREFCNT_inc(body);
hv_store(hdr, "__BODY__", 8, body, 0);
any more. There are just *way* too many little fiddly functions to peer
around in Perl's guts, which to me is evidence that we don't have enough
abstraction. It's not too bad if you do simple things, but as soon as you
do something slightly off the main sequence (such as the above, which
stashes a window to a separately allocated piece of memory into a Perl SV
and marks it read-only), you have to do all sorts of grotty fiddling on
the basis of very little documentation.
> It is very easy to create something that is unacceptably slow and not
> realize until toward the end of the process.
It's also important to solve performance problems with redesigns and
faster algorithms and not rely on incremental micro-optimizations, which
means you have to catch them early enough to know where those redesigns
are necessary before you've written all the code. Or to put that a better
way, I'd like to see a Perl that's about as fast as Perl 5 *before* we
start in on the profiling and searching for hot-spots for narrow
optimizations, which means a lot of thought given to more efficient and
better data structures, and probably means a lot of research into what's
new in tactics and tricks since Perl 5 was written.
It may be a pipe dream, but I want it. :)
Now's the time to change everything, if theory has kicked out new widgets
that no one had fully analyzed back when Perl 5 started.
--
Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/>
