Boost logo

Boost :

Subject: Re: [boost] [AFIO] Formal review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-09-02 20:20:08

On 3 Sep 2015 at 1:53, Andrey Semashev wrote:

> >> Race-free API may be interesting on its own, but apparently being
> >> race-free hampers performance, which is essential for the first goal.
> >
> > Again, I repeat the point about control and worst case behaviour.
> >
> > AFIO can and does produce superb file system performance an order of
> > magnitude or more in excess of anything achievable with the STL or
> > anything in Boost. But you'll need to completely rewrite your
> > algorithms according to file system theory first.
> I'm sorry, you lost me here. You just said that AFIO, being an async
> library, will always be slower than STL, and now you say its performance
> is superb?

I'm just about to go to bed and we go on family holiday tomorrow
before which I'll unsubscribe from boost-dev until January. But just
to answer the above, if you program AFIO using the same algorithms
and programming model as the STL you will almost always get slower
code. AFIO provides much stronger guarantees, and ASIO adds more

With AFIO you can use algorithms and models much more tightly aligned
with how filesystems actually work. Designs not possible with the
STL. Such designs can be an order of magnitude faster or better.

You can see what I mean in the workshop tutorial where the first
example is written using STL iostreams, the second and third using
AFIO but also using a file per key-value. The fourth example has its
design described in detail and as you will quickly realise, such a
design is not possible with the STL or anything currently in Boost. I
would expect lookup performance to be at least 10x-1000x faster and
write performance at least 10x faster than the STL compatible design
of a file per key-value.


ned Productions Limited Consulting

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