Anything you can do to re-order parsers to avoid backtracking is good. So if you try to match number before matching identifier you don't need to have identifier exclude numbers.
You will need to profile your parser and see what the bottle neck is. Once you have worked out the bottle neck, check out: * https://github.com/kschiess/parslet/blob/master/qed/accelerators.md * https://github.com/kschiess/parslet/blob/master/example/optimized_erb.rb --- "No man is an island... except Philip" On Mon, Dec 15, 2014 at 6:49 AM, Nigel Thorne <[email protected]> wrote: > You can remove a few of your 'absent?' checks. That may help. > > On Sun, 14 Dec 2014 21:51 José Leitão <[email protected]> wrote: >> >> >> >> Hi, >> >> First of all I would like to congratulate you on your work in Parslet gem. >> >> I think it is very well documented and easy to use for beginners like >> myself. >> >> I would like to kindly ask for your help on a project I am just starting >> in Ruby , in which I intend to use Parslet extensively. >> >> I have started to develop a simple parser for LEF files, and I have tried >> to keep it as general as possible. However, although the program is able to >> parse it correctly it takes an enormous amount of time ( ~15 seconds in a i7 >> ) to parse a 3000 line file. >> >> Could you please check the ~70 lines of code of the parser ? The code is >> at: >> >> https://github.com/zml/eda/blob/master/lib/eda/lef/parser.rb >> >> I am sure I am making some kind of rookie mistake in the parser... unless >> it is really inadvis able to make it general as I have tried to make it. >> >> I really hope you can give me some helpful hint so I can contribute with >> my own gem to the amazing Ruby community ;) >> >> Thank you! >> José M. Leitão
