Boost logo

Boost :

Subject: Re: [boost] My Beast Review
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-07-12 00:08:51

On Mon, Jul 10, 2017 at 1:22 AM, Seth via Boost <boost_at_[hidden]> wrote:
> 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

> 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.)

Boost list run by bdawes at, gregod at, cpdaniel at, john at