On 28.02.2017 18:10, Jacek Caban wrote:

On 28.02.2017 16:44, Sebastian Lackner wrote:

Well, there are also situations where it would be relatively easy to avoid
the roundtrip. We could return immediately at least when no events, APCs or
completions are involved, right? Since this is the most common situation it
might still be worth the effort.

If event is not passed, we still need to signal object itself. Thinking
about it some more, I guess we could just signal object it before
returning for non-overlapped operations returning immediately. It
wouldn't be exactly right, but it can't be used for synchronization
reliably in this case anyway.

Another thing is that we currently don't know if there is user APC until
APC_ASYNC_IO returns, but that can be fixed.

Since it's just an optimization, can we process with the patch itself
first? I'm happy to optimize that, but I find it hard to agree that an
optimization should block inclusion of patches targeted at correctness.

I'm not saying that it should block anything, I will leave the design decision
up to Alexandre. Nevertheless, I think it certainly makes sense to discuss
about such aspects in advance. Depending on the solution used it might also
require refactoring of this patch, which is easier to do before it was accepted.

I drafted an optimization discussed in this thread. It's just a proof-of-concept. A better implementation will store user APCs on server side when the async is created and I'd consider moving handling of returned data and wait handle out of fd-specific ops. I ran it on my benchmark from last year [1] and it was 2 times slower than what I called "plain wine+msgmode patchset+optimizations". It's expected, since with that we need two server calls (that one needed one). Going down to one server round-trip for simple cases is easy with that and should give about equal results.

The point is, named pipe code needs just small changes for such optimization, no refactoring. I hope that addresses your concerns.

Jacek

[1] https://www.winehq.org/pipermail/wine-devel/2016-October/115071.html