in reply to Re^3: Suggestion for regular expression speed improvement.
in thread Suggestion for regular expression speed improvement.

As I mentioned above, I would not be able to take that approach. Since, I want to enable support to match log lines of any format with grouping. If I go by CSV, then I would not be able to parse other formatted logs like syslogs and other proprietary logs.
  • Comment on Re^4: Suggestion for regular expression speed improvement.

Replies are listed 'Best First'.
Re^5: Suggestion for regular expression speed improvement.
by demerphq (Chancellor) on Jun 15, 2009 at 14:25 UTC

    You need to think out of the box. Make your system handle the various cases. A regex, a split, an unpack, maybe even an xml parser....

    Definitely doing it the way you are is wrong. If you are really insistent on ignoring our advice (unwise really), then at least use inversion and you might want to investigate the (?>...) construct "atomic matching". As well as adding anchors to your pattern.

    ---
    $world=~s/war/peace/g

[reply]
      Make your system handle the various cases. A regex, a split, an unpack, maybe even an xml parser....

      I agree. The simplest solution is to make the caller supply a code reference, which you then call and which does the parsing/matching/unpacking/whatever.

[reply]
      Exactly. This was my approach but before taking that up I wanted to check with the community whether Im doing anything wrong with regular expression. May be I expected too much from the regular expression. Anyway, thanks for your inputs :)
[reply]

        Well no, its just that if you use a big huge complex machine to do the work that you could do with a knife that you arent being efficient.

        And split does use the regex engine, its just it uses it in special ways to be efficient.

        ---
        $world=~s/war/peace/g

[reply]

In Section Seekers of Perl Wisdom