So you're saying that it's ok if people wouldn't want to upgrade on the
basis of one of the improvements, but rather that the aggregation of all
of them had damn well better be worth upgrading for. Fair enough. But
hey, people won't even upgrade to 5.6; when someone asks me "why should
I upgrade to Perl6" I don't want the conversation to continue:
"Because it's faster."
"How much faster?"
"10%"
"Oh. Good. What else?"
I'd be happier with a single good answer to that question for a whole
range of people -- those who care about speed, those who want write
their scripts faster, those who want to get their scripts right faster,
etc. It doesn't have to be all of those things at once (consider
optional type checking), and I may have to dig up an answer for the
specific thing that that person cares about.
But (again trying to shut up) this isn't directly relevant to the
project goals. If we'll make a better Perl6 by shooting for a 10%
overall speedup rather than a 100% speedup only on grepping bytes off of
a socket, then let's shoot for 10%. The argument for the 10% goal is
pretty persuasive -- quantifiable but still generally applicable. And I
regard speed as more of a "it'd better be as good as perl5.001 or you
guys are going the wrong way" than a make-or-break for the upgrade
question.
So I'll shut up. :-)
You did ask at one point for some suggestions of other speed goals. So
here are example subgoals:
1. Methods are close enough in speed to subroutine calls (<=20% slower?)
that nobody will avoid using them for performance reasons.
2. A fairly tight loop with a subroutine call is <N% slower than the
same loop inlined.
3. Parsing a binary data file and converting it to ASCII output should
be within N% of the equivalent program written in C (assuming a very
simple conversion).
4. A minimal complete CGI program using CGI.pm =~ p526 should be N%
faster (Exporter.pm speedup.)
5. Regular expressions do not get slower. Oops, I mean: are >N% faster.
6. Grepping for a variable-sized regular expression on a nonblocking
pipe is >N% faster (with incremental regular expression matching, N can
be superlinear.)
