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

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.

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: NO PERL 6
by John M. Dlugosz (Monsignor) on Dec 13, 2002 at 15:56 UTC
    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]
        Since the Perl 6 implementation itself will use (non-trivial) patterns to compile the script, I suppose they will be well tested and tuned.
[reply]

In Section Meditations