Write a Parser Performance special topic

[epage]

We should help people in optimizing their parsers, including

• Link out to https://nnethercote.github.io/perf-book/ for people to profile and do other things
• Encourage dispatch over alt
• Use BStr parsing over str when possible
• Optimizing for common cases (capture unescaped string, then fallback to escaping support)

See https://epage.github.io/blog/2021/09/optimizing-toml-edit/ for other ideas

We should use the json parser as the guide. We could show diffs of the examples to show what the changes look like.

Open questions

• Should we show a progression (naive json, dispatch json, dispatch + byte json) or show them individually with a single "complete" version for benchmarking (naive json, dispatch json, byte json, dispatch + byte json)

[epage]

Specifically cover the cost of large return types which can show up in surprising ways like just using a tuple (#237)

[epage]

Other sources of ideas

• https://nodebb.org/blog/optimizing-benchpress/
• https://news.ycombinator.com/item?id=8680214
• https://news.ycombinator.com/item?id=23662540
• https://news.ycombinator.com/item?id=38150833

[praveenperera]

Specifically cover the cost of large return types which can show up in surprising ways like just using a tuple (#230)

@epage This is a question I had, when you say watch for large return types. Is it better to call parse_next multiple times and use regular if else branching?

Instead of trying to purely do it all with combinators?

Examples and more context: https://www.perplexity.ai/search/rust-nom-and-winnow-parsing-is-SaJuUbDxSfu09wjpXcOctA

Though in my example, I’m not actually returning, the tuple.

[epage]

FYI I've updated my post to point to #237 which is a more appropriate place to discuss that. Moving this thread there.