Gentle People:
I know that this is a bit off from the current thread but consider
this:
"Few mallocs is good" Why?
One issue is that in many (all) Operating Systems malloc is a system
call,
where a system call causes one or more context switches. Where each
context switch is considered high overhead ( read that time).
Consider this: What if you create your own local malloc, which I will
call LMalloc(). LMalloc is initialized with a very large block via a single
initial call to malloc, keeping in mind that this could be increased later,
with the goal of a very very few large calls to malloc.
When the user wants memory via the traditional malloc() he uses
instead LMalloc() where LMalloc maintains a local memory management pool
and allocates memory on request. At the User Program API the User sees
LMalloc() behave EXACTLY like malloc() (WITHOUT SYSTEM CALLS).
Thomas Dineen
On 2/1/2022 4:46 AM, Henrik Holst via curl-library wrote:
Tried it quickly in the compiler explorer and gcc 11.2 did not detect
that it could convert it to a strcpy. It did a strlen+memcpy just as
the source code suggests.
/HH
Den tis 1 feb. 2022 kl 13:17 skrev Cristian Rodríguez
<crrodrig...@opensuse.org>:
On Tue, Feb 1, 2022 at 8:33 AM Henrik Holst via curl-library
<curl-library@lists.haxx.se> wrote:
>
> did find one low hanging fruit and one interesting strcpy
reimplementation:
> --- a/lib/urlapi.c
> +++ b/lib/urlapi.c
> @@ -1005,9 +1005,7 @@ static CURLUcode seturl(const char *url,
CURLU *u, unsigned int flags)
> return CURLUE_NO_HOST;
> }
>
> - len = strlen(p);
> - memcpy(path, p, len);
> - path[len] = 0;
> + strcpy(path, p);
>
Did the generated code change on this bit though ? I believe gcc
recognizes both variations (the original and strcpy) and will change
it to stpcpy or memcpy..
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
