On Mon, Jul 10, 2017 at 1:22 AM, Seth via Boost
Boost has an excellent library for fast and versatile parsing. Using it instead would at once lend a level of testing infeasible with the hand-written code here AND make sure it runs on all target architectures, as well as on any type of iterators.
If you mean Boost.Spirit then from my experience it is not always the best tool. Not that I benchmarked that code much but I had a number of cases when it was actually easier to write the correct parser by hand than to express all the corner cases and error handling in Boost.Spirit. The resulting code looks cleaner and more easy to follow (for me, at least). This is most often the case for micro-parsers. And obviously, hand-made parsers are almost always faster to compile. As an example, settings parsers in Boost.Log were initially implemented in Boost.Spirit. There was a lot of criticism at that time that Boost.Log was too heavy to compile and the binaries were huge. I had to rewrite most of the parsers by hand to alleviate the problem. I didn't review Beast implementation and I can't tell whether Vinnie's choice was justified, but I can understand why he could make that choice.
I think indeed premature optimization does not benefit the library - certainly in this stage of adoption.
I can argue that there is no such thing as too much performance. There's a balance with maintainability and other concerns, but as long as other requirements are satisfied, more performance is always welcome. And in many areas performance is the key point, so having faster code would certainly help the adoption. I'd like to support Vinnie in his willingness to write and maintain code with the aim at performance. (Of course, as long as the performance is actually improved according to benchmarks.)