5 ms·
How to write a really fast parser without going insane
- wglb 17y agoError establishing a database connection.
- ecaron 17y agoGoogle's cache of the article: http://74.125.95.132/search?q=cache:www.serpentine.com/blog/2010/03/03/whats-in-a-parser-attoparsec-rewired-2/ http://74.125.95.132/search?q=cache:www.serpentine.com/blog/...
- BudVVeezer 17y agoPretty light on actual information...
- pmjordan 17y agoYeah, I wish he'd explained what actually made it so fast.
- johngunderman 17y agoYou could always check it out yourself: http://hackage.haskell.org/package/attoparsec http://hackage.haskell.org/package/attoparsec Although I'm not sure if he's pushed the most recent changes yet.
- pmjordan 17y agoMy Haskell skills are practically non-existant, certainly not good enough to jump into that project and understand what's going on. I was hoping for a more high level explanation of what he was doing.
- andrewcooke 17y agoisn't attoparsec a haskell parser? is it lazy? i am wondering if it's fast because it's not actually doing the parsing... (ie it's returning thunks that will require more evaluation before providing, say, an AST).
- deleted 17y ago[deleted]
- jmillikin 17y agoThe article is written by Bryan O'Sullivan, author of the criterion[1] and text[2] packages and co-author of Real World Haskell[3]. If he's not the world's foremost expert on Haskell performance, he's certainly in the top 5. This benchmark undoubtedly takes laziness into account. [1] http://hackage.haskell.org/package/criterion http://hackage.haskell.org/package/criterion [2] http://hackage.haskell.org/package/text http://hackage.haskell.org/package/text [3] http://www.realworldhaskell.org/ http://www.realworldhaskell.org/
- andrewcooke 17y agook! (i didn't mean it as personal criticism - i am currently debugging/tuning my own recursive descent library (lepl) and am having a world of pain with memoisation, which is a similar problem...). bryan, if you see this, more info on what makes that lib so fast would be greatly appreciated!
- jmillikin 17y agoIf you need to do any sort of benchmarking for Haskell libraries, I can't recommend Criterion (and Neil Brown's package Progression[1]) enough. It handles all the details for lazy evaluation (NF vs WHNF, pure vs IO, etc) quietly behind the scenes, and uses a well-designed statistics analysis library to calculate the final numbers. Don Stewart has written a short introduction, Modern Benchmarking in Haskell[2]. It's worth mentioning that Criterion can be used for anything that can be called via the FFI -- I'm using it for benchmarking Python libraries, for example. [1] http://hackage.haskell.org/package/progression http://hackage.haskell.org/package/progression [2] http://donsbot.wordpress.com/2010/02/23/modern-benchmarking-in-haskell/ http://donsbot.wordpress.com/2010/02/23/modern-benchmarking-...
- Periodic 17y agoThe title here seems to be inaccurate. The title of the post--based on the Google cache--is "What’s in a parser? Attoparsec rewired (2/2)". It's not actually about building parsers so much as comparing the new Haskell attoparsec parser to C parsers. I'm glad to see this improvement being made in the LL parsers in Haskell. They're much more natural to write than parsers with a bottom-up parser generator. I believe Happy is the major parser-generator for Haskell and since it uses YACC-like syntax for the grammar it starts to feel like I'm writing C into my Haskell code. Parser-generators always feel a bit ugly, but they usually yield the most efficient and fastest code.