in reply to Is this a job for Parse::RecDescent?

It could be a job for Parse::RecDescent. But Parse::RecDescent is well, a recursive descent parser. Which means, it doesn't take short cuts. It's very general. It will explore and explore and explore, and backtrack and explore and explore and do some more backtracking, and then start all over again before deciding "nope, no way, absolutely no way this is going to match". While powerful, it's not efficient.

Your syntax looks simple enough that you can parse it with a limited look-ahead parser, which doesn't backtrack more than the number of tokens it looks ahead.

Usually, much faster. But you may have to do a lot more work to have a parser. So, you have to make a trade off. How much programming time are you willing to spend to speed up the runtime. Of course, if the files you're going to parse are small, or if the grammar is simple, or if the data is such that it never backtracks anyway, Parse::RecDescent maybe fast enough anyway.

There's no easy answer to this question.

  • Comment on Re: Is this a job for Parse::RecDescent?

Replies are listed 'Best First'.
Re^2: Is this a job for Parse::RecDescent?
by ikegami (Patriarch) on Nov 29, 2010 at 23:50 UTC

    It's not hard to write a single-token lookahead parser with P::RD. There's no reason to do any backtracking with that grammar. That doesn't mean P::RD isn't slow.