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.
Re: Fewer mallocs is better, episode #47
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Thomas Dineen via curl-library <curl-library_at_lists.haxx.se>
Date: Tue, 1 Feb 2022 12:38:04 -0800
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
> <crrodriguez_at_opensuse.org>:
>
> On Tue, Feb 1, 2022 at 8:33 AM Henrik Holst via curl-library
> <curl-library_at_lists.haxx.se> wrote:
> >
> > did find one low hanging fruit and one interesting strcpy
> reimplementation:
>
> > --- a/lib/urlapi.c
> > +++ b/lib/urlapi.c
> > _at__at_ -1005,9 +1005,7 _at__at_ 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..
>
>
Date: Tue, 1 Feb 2022 12:38:04 -0800
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
> <crrodriguez_at_opensuse.org>:
>
> On Tue, Feb 1, 2022 at 8:33 AM Henrik Holst via curl-library
> <curl-library_at_lists.haxx.se> wrote:
> >
> > did find one low hanging fruit and one interesting strcpy
> reimplementation:
>
> > --- a/lib/urlapi.c
> > +++ b/lib/urlapi.c
> > _at__at_ -1005,9 +1005,7 _at__at_ 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.htmlReceived on 2022-02-01