No, though I do think a synchronous API is easier to work with. It isn't synchronicity that is slower. There are lots of socket-level options and buffer allocation options that need to be set up right for raw data transfer to go quickly. And the API needs to make it easy to avoid copying arrays of bytes. And I do have benchmarks for those.

When I first implemented this class, I was upgrading a file caching client that talked to a custom file server. It kept about 80,000 files (about 16GB) in sync with the set of files on the server. The unoptimized Mac process started out about 40% slower than the Windows equivalent client. Afterwards, the Mac client was about 15% faster than Windows with no changes on the server. They couldn't get the Windows client to transfer as quickly as the optimized Mac client.

Could these optimizations be done in an asynchronous API? Sure. But as far as I can tell, none do. Maybe because they don't work directly with sockets. Normally that isn't a problem, unless you really need to push things across the network as fast as possible.

In my case, I had 30-100 clients taking turns trying to transfer a those files across the network. The difference in total time to complete was often measured in hours.