2017-05-28 0:17 GMT+02:00 Niall Douglas via Boost
But Outcome was always written for a SG14 low latency type audience. The group is a bit misnamed, they actually much prefer predictable latency over low latency. Some over there even compile release code with -O0 to ensure they get exactly the performance of the source code written, no surprises. That sort of thing.
As I mentioned before, if identical performance for success vs failure is not what you want, and you really care about 20 CPU cycles, expected
will always bias towards either T or E. Interesting. Did I missed that in the docs? According to your description it should be really relevant to people who make a decision whether to go with your library or not.
People who actually care about 20 CPU cycles per branch on state will without fail insist on examining the source code before deciding on using a library. They wouldn't trust claims in its documentation. Therefore I didn't bother documenting it publicly, I let the code speak for itself.
You do not make these claims so that people just trust you. You make them to encourage people to examine the sources. Also, I believe that if I were interested in this performance guarantee, I would like it documented, because it is a guarantee that what I see in the code is not a happenstance of this GIT SHA, but a feature you commit to supporting. I, for one, am not interested in these optimizaitons, but if I have seen them documented, I would have a slightly better understanding on what goals of this library are. Regards, &rzej;