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 work. 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. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/