On Sat, Aug 22, 2015 at 9:38 PM, Niall Douglas
On 22 Aug 2015 at 19:43, Glen Fernandes wrote:
Am I to understand that by design, AFIO's implementation implies lower performance than an alternative? (even if that alternative is something like libuv, which has its own flaws)
Current performance benchmarks can be found throughout the documentation, specifically the tutorials, the release notes and the reference documentation.
Is it lower performance than alternatives? Almost certainly, and the documentation takes pains to present AFIO in a worst possible light in any comparative benchmarks presented so nobody is under any illusions. What matters is correctness, reliability, reusability and portability - and most importantly of all - do NOT lose other people's data.
Sorry, but I have to disagree tremendously. Performance is the only justification I can give clients (and bosses) of having such complex code as asynchronous programming requires. Justifying Boost.ASIO is an exercise in marketing, and the benchmarks are the killer chart that sell complexity. If not by that, Qt would be the chosen path in many non-academic projects. I even see a use case for AFIO in one of my products, where extreme write performance with minimum IO is a first priority, and a big effort was made to implement a subsystem for fast writes under the specific environment. Effort so big that the project froze until the writer code was done. The point of this is that performance should not be low priority. Specially for a boost library, and even more so for an asynchronous library. Citing correctness is not a feature to me. It's just basic principle. You are assumed to have it. As soon as AFIO is really competitive for me to use, I wish to do a full review. As for the general API usage I'm not sure that a full blown review is needed for that. The library is not finished, and you said, and a review now will be just like our past review, where a very interesting library is just not ready yet. And in your case, it doesn't yet perform. Reviewing of incomplete library work is not ideal, IMHO. That being said, I have some questions: Benchmarks, Do you have usable coroutines examples now? The web sample uses futures. Do you have better performance numbers when using them? What good measures did you employ to prevent caches from contaminating benchmarks? Do you believe that performance will improve? Do you know what your bottleneck is? Why do other libraries do better? Can you imitate that while still leaving your superior API? About coroutines, Do you really need C++1z? Why not Boost.Coroutine emulation for backwards support? Why do you use C++11 at all? C++03 is still widespread and a requirement for most projects still. Thank you for your time, Rodrigo Madera