Is libcURL slower than hand creating socket requests in C?

<i>I still haven&#x27;t answered a very important question. Why is libcUrl so much slower?</i><p>I would be very hesitant to be giving this kind of advice until i had an answer to that.

Far too little detail in this post.. e.g. how was the application handling the curl callbacks? I fixed one app that used repeated strcat() calls (which was never correct.. it was also handling binary data)<p>Would be nice if OP profiled his new code vs. his old code, though I&#x27;m guessing libcurl isn&#x27;t the issue even without seeing profiling results

A curious result, but the conclusion is ridiculous. I can think of a handful of explanations for this result, none of which would implicate libcurl.<p>-Incomparable harnesses<p>-Misuse of the library&#x27;s api<p>-Build switches<p>-UA sniffing<p>-Not measuring or controlling for system&#x2F;net load<p>This isn&#x27;t a post about why you shouldn&#x27;t use libcurl; it&#x27;s a post about why you shouldn&#x27;t benchmark your way to blind conclusions.

Given the final paragraph:<p>&gt; I still haven&#x27;t answered a very important question. Why is libcUrl so much slower?<p>I&#x27;d assume it&#x27;s likely a result of misuse of libcUrl, or cUrl properly implementing some part of the spec that this hand-rolled implementation ignores.<p>On top of this, the author&#x27;s C code isn&#x27;t very well written. There&#x27;s use of `sprintf` without arithmetic bounds checks (really he should use `snprintf`), unnecessary construction of a one-character array (that&#x27;s what a dereference is for), inconsistent whitespace, `malloc` when a stack allocation would make more sense, use of `unsigned char` instead of `char` for strings, etc.<p>From what I can tell, the libcUrl guys are serious about performance, and I have trouble believing such a wild allegation without any further analysis.

Smells of a DNS cache issue. Maybe libcurl is using its own resolver? I know at least it has its own in-process DNS cache that for example may not be activated by default with the easy API. Or that it can be compiled with c-ares support, etc.

Would it not be more likely that libcurl is battle-tested and adds layers upon layers of validation, correction, ssl support, cookie management and what not that hand-crafted requests don&#x27;t?

I recently tested some software that used libcurl, and it was also horrendously slow. I don&#x27;t remember libcurl being so slow when I used it for a project a few years ago. It makes me wonder whether some more recent change made things a lot worse, at least for some configurations. Maybe it&#x27;s DNS-related, as some have suggested. This is probably neither experimenter error nor the last word on the subject. More likely, it&#x27;s a strong signal that there&#x27;s something here worth investigating.

I had to search on hn.aloglia because this ridiculously bad science got rightfully killed.<p>Did the OP even test with ruby&#x2F;python&#x2F;wget&#x2F;curl ? Could be a DNS issue and nothing to do with libcurl.<p>Why spend all that time and not run `gprof` ?!

Title should be &quot;libCurl is slow&quot; since the article fails to present any alternative other than &quot;make your own&quot;, which is unfeasible in many situations.

It seems kinda suspicious that 50 requests and 5 MB takes as long as 1000000 requests and 100 MB. It makes me think that something is wrong with your benchmark.

It&#x27;s suspicious that doing N requests of 100 bytes is slower than doing N requests of 10000 bytes. That doesn&#x27;t pass the sniff-test for me.