On Fri, 1 Jul 2016, Ray Satiro via curl-library wrote:

> It seems possible you could actually hurt performance in some cases and end
> up doing the opposite of what you intended.

Yes that's true, but the question for me is how often it is likely to be good
vs bad. How much of or protocols these days are lots of smaller pieces send
back and forth and how we handle that internally already.

Clearly TLS handshakes improve significantly with this option set. That's a
significant amount of all transfers. HTTP is more or less unchanged, unless
for repeated HTTP requests where setting this option helps. The pingpong
protocols where we send lots of tiny commands and wait for a response, should
improve. SFTP should also benefit from it for the same reason.

> Maybe there are some specific scenarios where all users could get provably
> better performance using NODELAY but using it for everything seems too far.
> Can you make a better case for this? I haven't seen enough to back this up
> so for now I vote -1.

Well, you could also turn that around. Previously we had it _disabled_ for
everything (except HTTP/2) when clearly a huge amount of protocols would
benefit from having it enabled.

We could of course make the enabling a more fine grained thing. Which
protocols would you suggest we should not have it enabled for? I can't think
of any obvious candidates since we're buffering internally anyway for most of
the cases that I can immedaitely think could hurt from this (like Dan's
mentioned case if we had been sending request headers one by one or similar).

I just think it helps more than it hurts so switching the default seems
reasonable.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html