in reply to Re: Alternations and anchors (trie optimization)
in thread Alternations and anchors

Thanks! I guess that explains it. I'm not sure why ((?:^(?:aaa|bbb|ccc))|(?:ddd|eee|ccc)) can be optimised but not (?:^aaa|ddd), but it is what it is.

Replies are listed 'Best First'.
Re^3: Alternations and anchors (trie optimization)
by LanX (Saint) on Apr 02, 2025 at 16:50 UTC
    > I'm not sure why ((?:^(?:aaa|bbb|ccc))|(?:ddd|eee|ccc)) can be optimised but not (?:^aaa|ddd),

    As I said:

    Because "aaa" is a string of literal characters but "^aaa" isn't. "^" is a meta symbol for anchoring. The literal character is "\^", but that's not what you want.

    If you need better explanation how trie works, please follow the links I provided.

    The long answer

    It certainly could be implemented for surrounding anchors too, just by using the workaround I showed.

    But it's normally a bargain between code complexity and trade-off.

    Perl's source is already suffering from covering too many edge cases which are only of interest for a small minority of users. And they shout the loudest when backwards compatibility is broken.

    At the same time the code is getting increasingly complicated to maintain.

    For instance: you could volunteer to implement a solution which creates multiple trie alterations surrounded by different anchors. (Not trivial to test)

    Then someone with a commit bit has to decide if it's worth the resulting trouble to test and maintain that code in eternity.

    In the end it's strategically easier to provide a CPAN module covering this edge case.

    Usage would show if it's of wider interest or just pleasing you and a handful of others.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

      Usage would show if it's of wider interest or just pleasing you and a handful of others.

      Without knowing more about the OPs specific use case, i certainly don't know if this attempt at optimization is actually required or if we're dealing with an X/Y problem here.

      For example, if the input dataset is refered often, but hardly ever changes, caching the parsed results might decrease wait time orders of magnitude more in the long run than trying to optimize the parsing time. If new or changed data is also not used immediately, throw in a bit of pre-computing, and we're basically down to the time it requires to read a file from disk (and even then there are ways to optimize it, for example by pre-caching in RAM).

      PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
      Also check out my sisters artwork and my weekly webcomics
        You are essentially saying that improving the regex engine is not necessary because you can preprocess any input in a database.

        It's like saying improving Perl's speed is nonsense, you can always use C or Assembler instead.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery