5 ms·
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. -Incompara
by aegiso 12y ago
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.
-Incomparable harnesses
-Misuse of the library's api
-Build switches
-UA sniffing
-Not measuring or controlling for system/net load
This isn't a post about why you shouldn't use libcurl; it's a post about why you shouldn't benchmark your way to blind conclusions.
- konceptz 12y agoAuthor here: You're right about the conclusion, I'll reword the title. As far as why, my calls are certainly in the post somewhat buried in the github code linked to directly on the post. Certainly more attention should be paid to how testing was done, I'll update that later tonight.
- hobofan 12y agoIf you do benchmarks you should also keep in mind that EC2 micro instances are terrible because they have highly variable CPU speeds which will be greatly reduced if the CPU load is high for a short time.
- konceptz 12y agoThis is very interesting, it's the first I've heard of this but I have experienced some issues implementing pthreads. This could be a reason. Do you know where I might find some documentation on this?
- hobofan 12y agoThere is only a small part on the EC2 website, where Amazon is mentioning it, as far as I know. However there are some blog posts about it: http://blogs.adobe.com/digitalmedia/2011/02/amazon-ec2-micro-instance-and-stolen-cpu/ http://blogs.adobe.com/digitalmedia/2011/02/amazon-ec2-micro... http://hughht5.blogspot.de/2012/05/amazon-ec2-micro-instance-and-stolen.html?m=1 http://hughht5.blogspot.de/2012/05/amazon-ec2-micro-instance...