Buy commercial curl support. 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 Daniel himself.
Re: Increase in CPU usage in 8.7.1 vs 8.6.0 for rate-limited downloads
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 21 Jun 2024 00:23:56 +0000
* Given such an option, then when desired you could also use it to specify _more_ precision than the current default behavior provides.
Actually, the current behavior is quite precise and stable.
I tested it on a wide variety of download sizes and network speeds, and the measured speed deviations in all my test cases were always less than 2%.
Not sure, if anyone would need more precise speed limits than that.
Whereas the new changes that added less precise speed limits in 8.6.0 but with a bit less CPU utilization introduced very varying throttled speeds with observed speed deviations above 20% in some cases.
Such large and not stable speed deviations were obvious regression compared to the previous versions, like 7.84.
I was thinking about build option because I couldn’t envision that some application would want to use both reliable and unreliable speed limits in different transfers.
For me, it is either needed to use reliable speed limits in all application transfers (my case) or application doesn’t care about speed limit precision at all.
Also, providing code for both precise and not precise speed limits on per-handle basis, will definitely increase the libcurl size, which may be critical for embedded systems (my case again).
Thanks,
Dmitry Karpov
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of David Pfitzner via curl-library
Sent: Thursday, June 20, 2024 4:10 PM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: David Pfitzner <dpfitzner_at_netflix.com>
Subject: [EXTERNAL] Re: Increase in CPU usage in 8.7.1 vs 8.6.0 for rate-limited downloads
On Fri, Jun 21, 2024 at 4:06 AM Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se<mailto:curl-library_at_lists.haxx.se>> wrote:
That basically means that you are asking for a new feature (i.e. build option etc), which would allow you to sacrifice speed limit precision but will limit CPU usage during throttling.
Actually, I wasn't thinking of a build option, but rather a per request (CURLOPT_FOO) option. Yes, it would be a new feature.
For my use cases, it is not an option I would like to use – I need to have a quite precise speed limit for my application (which both 8.7.1 and 7.84 provide) and somewhat higher CPU usage price for a precision is not an issue for me.
Given such an option, then when desired you could also use it to specify _more_ precision than the current default behavior provides.
-- David
Date: Fri, 21 Jun 2024 00:23:56 +0000
* Given such an option, then when desired you could also use it to specify _more_ precision than the current default behavior provides.
Actually, the current behavior is quite precise and stable.
I tested it on a wide variety of download sizes and network speeds, and the measured speed deviations in all my test cases were always less than 2%.
Not sure, if anyone would need more precise speed limits than that.
Whereas the new changes that added less precise speed limits in 8.6.0 but with a bit less CPU utilization introduced very varying throttled speeds with observed speed deviations above 20% in some cases.
Such large and not stable speed deviations were obvious regression compared to the previous versions, like 7.84.
I was thinking about build option because I couldn’t envision that some application would want to use both reliable and unreliable speed limits in different transfers.
For me, it is either needed to use reliable speed limits in all application transfers (my case) or application doesn’t care about speed limit precision at all.
Also, providing code for both precise and not precise speed limits on per-handle basis, will definitely increase the libcurl size, which may be critical for embedded systems (my case again).
Thanks,
Dmitry Karpov
From: curl-library <curl-library-bounces_at_lists.haxx.se> On Behalf Of David Pfitzner via curl-library
Sent: Thursday, June 20, 2024 4:10 PM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: David Pfitzner <dpfitzner_at_netflix.com>
Subject: [EXTERNAL] Re: Increase in CPU usage in 8.7.1 vs 8.6.0 for rate-limited downloads
On Fri, Jun 21, 2024 at 4:06 AM Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se<mailto:curl-library_at_lists.haxx.se>> wrote:
That basically means that you are asking for a new feature (i.e. build option etc), which would allow you to sacrifice speed limit precision but will limit CPU usage during throttling.
Actually, I wasn't thinking of a build option, but rather a per request (CURLOPT_FOO) option. Yes, it would be a new feature.
For my use cases, it is not an option I would like to use – I need to have a quite precise speed limit for my application (which both 8.7.1 and 7.84 provide) and somewhat higher CPU usage price for a precision is not an issue for me.
Given such an option, then when desired you could also use it to specify _more_ precision than the current default behavior provides.
-- David
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-06-21