Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Fwd: libcurl read-like interface
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: XSLT2.0 via curl-library <curl-library_at_cool.haxx.se>
Date: Wed, 16 Dec 2020 12:38:07 +0100
> Probably by doing a first prototype implementation
> which can be used to run benchmarks.
Naive "reverse" benchmark adding an extra useless memcpy:
https://gitlab.com/BylonAkila/astreamfs/-/blob/master/benchmark/benchmark.c
Summary impact of a *single memcpy* on a typical HTTP GET: 11% to 15%
(depending mainly on CPU) on "user time".
You can repeat the tests with your own machine, instructions and
comments are in the short source.
There is absolutely no doubt "memcpy" takes a significant time and
should be carefully used... see how far they went Kernel guys: splicing!
I wanted to do a "more realistic" benchmark using fcurl, but it seems
bugged.
Question: would you think this "more realistic" test has any interest as
a "reverse" benchmark?
If so, I could try to debug and do some PR on fcurl.
Results are expected to be "equal or worse" than my simple test.
>You mean, the one that ends "Yet we should not
>pass up our opportunities in that critical 3%"?
That is a excellent question!
Does libcurl need "caller provided buffers" (aka "zero/less copies")?
To be honest, nor the "default behaviour" (stdout), nor writing to a
file would benefit from any "caller provided buffers" algorithm.
Indeed, when all you need to do is call write(), whether the buffer you
pass to write() is curl's internal or "caller provided" does not make
the slightest difference.
So yes, the valid question would be: how many users of libcurl need
something much more sophisticated than "writing to a file" with some
"decoration" around, and would benefit from "less copies"?
If the answer to that question is 97% of the users just "write to file"
(or equivalent), sure the bonus would be only for those 3%
Could an idea be to make that a "poll question" about that for next year?
As for my use case, I can confirm that a "fuse driver programmer" would
be happy with that extra feature (but we make do without it so far!).
If that is of any interest to this mailing list (not "out of topic"?), I
could give more details why working on a "fuse driver" with libcurl
would benefit from that.
But in the end, maybe you might say that this is "the 3%" and that
libcurl is not the right tool for "fuse drivers"!
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-16
Date: Wed, 16 Dec 2020 12:38:07 +0100
> Probably by doing a first prototype implementation
> which can be used to run benchmarks.
Naive "reverse" benchmark adding an extra useless memcpy:
https://gitlab.com/BylonAkila/astreamfs/-/blob/master/benchmark/benchmark.c
Summary impact of a *single memcpy* on a typical HTTP GET: 11% to 15%
(depending mainly on CPU) on "user time".
You can repeat the tests with your own machine, instructions and
comments are in the short source.
There is absolutely no doubt "memcpy" takes a significant time and
should be carefully used... see how far they went Kernel guys: splicing!
I wanted to do a "more realistic" benchmark using fcurl, but it seems
bugged.
Question: would you think this "more realistic" test has any interest as
a "reverse" benchmark?
If so, I could try to debug and do some PR on fcurl.
Results are expected to be "equal or worse" than my simple test.
>You mean, the one that ends "Yet we should not
>pass up our opportunities in that critical 3%"?
That is a excellent question!
Does libcurl need "caller provided buffers" (aka "zero/less copies")?
To be honest, nor the "default behaviour" (stdout), nor writing to a
file would benefit from any "caller provided buffers" algorithm.
Indeed, when all you need to do is call write(), whether the buffer you
pass to write() is curl's internal or "caller provided" does not make
the slightest difference.
So yes, the valid question would be: how many users of libcurl need
something much more sophisticated than "writing to a file" with some
"decoration" around, and would benefit from "less copies"?
If the answer to that question is 97% of the users just "write to file"
(or equivalent), sure the bonus would be only for those 3%
Could an idea be to make that a "poll question" about that for next year?
As for my use case, I can confirm that a "fuse driver programmer" would
be happy with that extra feature (but we make do without it so far!).
If that is of any interest to this mailing list (not "out of topic"?), I
could give more details why working on a "fuse driver" with libcurl
would benefit from that.
But in the end, maybe you might say that this is "the 3%" and that
libcurl is not the right tool for "fuse drivers"!
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-16