in reply to Re: Re: NO PERL 6
in thread NO PERL 6

In terms of arithmetic and other primitive operations, I'm sure Parrot will trounce the P5VM. This will be helpful in coding loops and testing limits and so on, the nuts and bolts of what holds a program together.

But individual features may get bogged down. For example, a while back I mused that Perl 6 Patterns would be much slower than Perl 5 Regex's because you can't tell it not to capture everything, and Abigail pointed out that this is not something you can optomize at compile-time without solving the halting problem.

So in Perl 5, I try and use built-in stuff even if in clever ways because it's faster than coding an explicit loop; in Perl 6 that will not be the case, but will I avoid grammars like the plauge because they are far slower than procedural code? That's my worry.

Replies are listed 'Best First'.
Re: Re: Re: Re: NO PERL 6
by Elian (Parson) on Dec 12, 2002 at 23:57 UTC
    There's no reason that perl 6 patterns will be any slower than perl 5 regexes. The equivalent constructs should take about the same amount of time, modulo the odd optimization on either side. (Likely the perl 5 regex engine will be faster by a bit to start, if for no other reason than a dozen years worth of vicious optimization inflicted on it)

    I'm not sure where you came up with the thought that you won't be able to limit what gets captured--you'll have at least as much control over capturing as you do now, if not moreso.

[reply]
      I'm not sure where you came up with the thought that you won't be able to limit what gets captured--you'll have at least as much control over capturing as you do now, if not moreso.

      See Perl6 regex/pattern performance issues? and the replies. Care to set the record straight?

[reply]
        Oh, OK, I see what you're talking about. No, that's not a performance issue. Named rules must be evaluated when used, of course, since otherwise we won't know what they match, and that's the expensive part. Remembering what they matched for the duration of the match is important as well for some regex optimizations I've had batted around. (And backtracking, of course--can't backtrack over a group thing without knowing its size, but that's no different than any other variable-length element) The only potential expense is the exportation of those matches, but since parrot does copy-on-write strings, that costs about two pointer stores and two integer stores.

        If that overhead is excessive, you can always nudge Larry to have non-capturing rule usage.

[reply]

In Section Meditations