malloc and calloc

Discussion in 'C Programming' started by Rahul Gandhi, Feb 2, 2004.

  1. Rahul Gandhi

    Rahul Gandhi Guest

    Which one is more fast?
    malloc followed by memset
    or
    calloc
    Rahul Gandhi, Feb 2, 2004
    #1
    1. Advertising

  2. On Mon, 02 Feb 2004 02:41:31 -0800, Rahul Gandhi wrote:

    > Which one is more fast?
    > malloc followed by memset
    > or
    > calloc


    That would depend on the plattform. If there is one it probably won't be
    big enough to matter. If you think it would then it's time for you to make
    measurements on your target platform.

    I wouldn't be surprised to see calloc implemented to just call malloc and
    then memset.

    --
    NPV

    "the large print giveth, and the small print taketh away"
    Tom Waits - Step right up
    Nils Petter Vaskinn, Feb 2, 2004
    #2
    1. Advertising

  3. "Rahul Gandhi" <> wrote in message
    news:...
    > Which one is more fast?
    > malloc followed by memset
    > or
    > calloc


    Red functions tend to go faster. But you'll have to do some profiling to
    determine the appropriate chromodynamic hue of each function.

    I.e. the standard doesn't impose speed requirements on functions. It's a
    'Quality of Implementation' issue.

    --
    Peter
    Peter Nilsson, Feb 2, 2004
    #3
  4. Rahul Gandhi

    Rob Thorpe Guest

    (Rahul Gandhi) wrote in message news:<>...
    > Which one is more fast?
    > malloc followed by memset
    > or
    > calloc


    It is platform dependent.

    But do you really care about the speed of malloc? If you do you have
    a part of your program that's not written very well.

    You will also find that it's quite common for 'free' to be by far the
    slowest.
    Rob Thorpe, Feb 2, 2004
    #4
  5. On 2 Feb 2004, Rahul Gandhi wrote:

    > Which one is more fast?
    > malloc followed by memset
    > or
    > calloc


    Try to implement
    a) malloc using calloc
    b) calloc using malloc
    ...and you'll see how much reason there is for either to be slower
    than another.

    Then it's up to you to decide whether your focus is reasonable and
    sane implementations. The standard doesn't mandate that. On
    DeathStation you might have to put ifdefs depending on whether you
    want less parallel throughput (several bytes/s for HPCSRNG) or
    more latency (sometimes days when waiting for other callocs to
    group with).
    Jarno A Wuolijoki, Feb 2, 2004
    #5
  6. Rahul Gandhi

    CBFalconer Guest

    Rob Thorpe wrote:
    > (Rahul Gandhi) wrote
    >
    > > Which one is more fast?
    > > malloc followed by memset
    > > or
    > > calloc

    >
    > It is platform dependent.
    >
    > But do you really care about the speed of malloc? If you do you
    > have a part of your program that's not written very well.
    >
    > You will also find that it's quite common for 'free' to be by far
    > the slowest.


    That will normally be because the system is searching for adjacent
    areas to combine, which may well be O(n) where n is the count of
    allocations and free blocks. This makes freeing a large
    collection of items O(sqr(N)). It is shown up quite dramatically
    in the test suite for hashlib, which in turn was the inspiration
    for nmalloc for the DJGPP system, where those two operations
    become O(1) and O(n) respectively. Both can be found at:

    <http://cbfalconer.home.att.net/download/>

    (nmalloc is freely available under the DJGPP license. Hashlib is
    under GPL).

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Feb 2, 2004
    #6
  7. Rahul Gandhi

    Alan Balmer Guest

    On Mon, 2 Feb 2004 22:04:31 +1100, "Peter Nilsson" <>
    wrote:

    >"Rahul Gandhi" <> wrote in message
    >news:...
    >> Which one is more fast?
    >> malloc followed by memset
    >> or
    >> calloc

    >
    >Red functions tend to go faster. But you'll have to do some profiling to
    >determine the appropriate chromodynamic hue of each function.


    But the blue ones are more critical, because they're coming toward
    you.
    >
    >I.e. the standard doesn't impose speed requirements on functions. It's a
    >'Quality of Implementation' issue.


    --
    Al Balmer
    Balmer Consulting
    Alan Balmer, Feb 2, 2004
    #7
  8. Rahul Gandhi

    Dan Pop Guest

    In <> (Rahul Gandhi) writes:

    >Which one is more fast?
    >malloc followed by memset
    >or
    >calloc


    In principle, calloc could be implemented as malloc followed by memset.

    However, it could skip the memset call if the allocated memory came
    directly from the OS (rather than being "recycled"), because many OSs
    clear themselves the memory they allocate to a program (for obvious
    security reasons).

    So, a calloc call need not be slower than a malloc plus a memset call,
    but it could be faster. I was deliberately ignoring the cost of the
    additional multiplication calloc has to perform (due to its interface).

    However, this should NOT be the criterion for choosing one or another.
    If your application needs zeroed memory, call calloc, otherwise call
    malloc.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Feb 3, 2004
    #8
  9. Rahul Gandhi

    Rob Thorpe Guest

    CBFalconer <> wrote in message news:<>...
    > Rob Thorpe wrote:
    > > (Rahul Gandhi) wrote
    > >
    > > > Which one is more fast?
    > > > malloc followed by memset
    > > > or
    > > > calloc

    > >
    > > It is platform dependent.
    > >
    > > But do you really care about the speed of malloc? If you do you
    > > have a part of your program that's not written very well.
    > >
    > > You will also find that it's quite common for 'free' to be by far
    > > the slowest.

    >
    > That will normally be because the system is searching for adjacent
    > areas to combine, which may well be O(n) where n is the count of
    > allocations and free blocks. This makes freeing a large
    > collection of items O(sqr(N)).


    Interesting, I've never actually looked at the time order of this. I
    just read the code to some malloc's once and noticed that free
    obviously did more work

    > It is shown up quite dramatically
    > in the test suite for hashlib, which in turn was the inspiration
    > for nmalloc for the DJGPP system, where those two operations
    > become O(1) and O(n) respectively. Both can be found at:
    >
    > <http://cbfalconer.home.att.net/download/>
    >
    > (nmalloc is freely available under the DJGPP license. Hashlib is
    > under GPL).


    I didn't know that, but I can see the sense in "shifting the work to
    the other side" in some cases. There are similar tradeoffs in GCs.
    Rob Thorpe, Feb 3, 2004
    #9
  10. Rahul Gandhi

    Malcolm Guest

    "Dan Pop" <> wrote in message
    > However, this should NOT be the criterion for choosing one or
    > another.
    > If your application needs zeroed memory, call calloc, otherwise call
    > malloc.
    >

    I would suggest malloc() followed by memset() for all occasions.
    calloc() is a trap for the unwary, since floating point types and pointers
    have all bits zero for 0.0 and NULL on almost all platforms, but this isn't
    guaranteed.
    Of course your application won't suffer from these problems, but another
    programmer looking at the code will be surprised to see a call to calloc(),
    and ask himself, "does the programmer who wrote this really know what he is
    doing?".
    In some environments it is a fairly common thing to trawl through code
    looking for allocations. Searches for "malloc" and "realloc" are
    unavoidable. If you have to search for "calloc" as well then it adds a layer
    of difficulty no-one needs.
    calloc() is a nuisance function that should be allowed to fall into disuse.
    malloc() followed by memset() indicates your intention to allocate a chunk
    of memory and initialise it to all bits zero.
    Malcolm, Feb 3, 2004
    #10
  11. On Mon, 02 Feb 2004 11:03:23 -0700, in comp.lang.c , Alan Balmer
    <> wrote:

    >On Mon, 2 Feb 2004 22:04:31 +1100, "Peter Nilsson" <>
    >wrote:
    >
    >>Red functions tend to go faster. But you'll have to do some profiling to
    >>determine the appropriate chromodynamic hue of each function.

    >
    >But the blue ones are more critical, because they're coming toward
    >you.


    /really/ REALLY fast.....

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
    Mark McIntyre, Feb 3, 2004
    #11
  12. In article <bvpb55$q7m$>,
    "Malcolm" <> wrote:

    > "Dan Pop" <> wrote in message
    > > However, this should NOT be the criterion for choosing one or
    > > another.
    > > If your application needs zeroed memory, call calloc, otherwise call
    > > malloc.
    > >

    > I would suggest malloc() followed by memset() for all occasions.
    > calloc() is a trap for the unwary, since floating point types and pointers
    > have all bits zero for 0.0 and NULL on almost all platforms, but this isn't
    > guaranteed.


    Excuse me, but malloc () + memset () has exactly the same problem!
    Christian Bau, Feb 4, 2004
    #12
  13. Christian Bau <> writes:
    > In article <bvpb55$q7m$>,
    > "Malcolm" <> wrote:
    >
    > > "Dan Pop" <> wrote in message
    > > > However, this should NOT be the criterion for choosing one or
    > > > another.
    > > > If your application needs zeroed memory, call calloc, otherwise call
    > > > malloc.
    > > >

    > > I would suggest malloc() followed by memset() for all occasions.
    > > calloc() is a trap for the unwary, since floating point types and pointers
    > > have all bits zero for 0.0 and NULL on almost all platforms, but this isn't
    > > guaranteed.

    >
    > Excuse me, but malloc () + memset () has exactly the same problem!


    I *think* Malcom's point is that memset() makes it more explicit that
    the memory is being set to all-bits-zero, whereas calloc(), being more
    implicit might lead the unwary to assume that floating-point values
    are set to 0.0 and pointers to NULL.

    I'm not convinced, either that Malcolm is right or that I'm correctly
    guessing what he meant.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    Keith Thompson, Feb 4, 2004
    #13
  14. In article <>,
    Keith Thompson <> wrote:

    > Christian Bau <> writes:
    > > In article <bvpb55$q7m$>,
    > > "Malcolm" <> wrote:
    > >
    > > > "Dan Pop" <> wrote in message
    > > > > However, this should NOT be the criterion for choosing one or
    > > > > another.
    > > > > If your application needs zeroed memory, call calloc, otherwise call
    > > > > malloc.
    > > > >
    > > > I would suggest malloc() followed by memset() for all occasions.
    > > > calloc() is a trap for the unwary, since floating point types and
    > > > pointers
    > > > have all bits zero for 0.0 and NULL on almost all platforms, but this
    > > > isn't
    > > > guaranteed.

    > >
    > > Excuse me, but malloc () + memset () has exactly the same problem!

    >
    > I *think* Malcom's point is that memset() makes it more explicit that
    > the memory is being set to all-bits-zero, whereas calloc(), being more
    > implicit might lead the unwary to assume that floating-point values
    > are set to 0.0 and pointers to NULL.
    >
    > I'm not convinced, either that Malcolm is right or that I'm correctly
    > guessing what he meant.


    Languages like Pascal did a certain amount of extra work for built-in
    functions like "writeln". The C language could in principle do something
    similar for calloc: Instead of calloc (nmemb, size) there could be an
    alternative calloc (nmemb, type) which would allocate an array of
    (nmemb) elements of the given type, each initialised like static
    variables would be initialised. For example, calloc (100, double) could
    with a little bit of support in the compiler allocate an array of 100
    doubles, each set to 0.0.
    Christian Bau, Feb 4, 2004
    #14
  15. Rahul Gandhi

    Dan Pop Guest

    In <> Keith Thompson <> writes:

    >I *think* Malcom's point is that memset() makes it more explicit that
    >the memory is being set to all-bits-zero, whereas calloc(), being more
    >implicit might lead the unwary to assume that floating-point values
    >are set to 0.0 and pointers to NULL.


    Even the unwary could ask himself: how could calloc guess which bytes
    are going to be used for storing floating-point values and/or pointers,
    from the available information: N objects of M bytes each?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Dan Pop, Feb 4, 2004
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jun Woong

    Re: Override malloc,calloc,realloc and free?

    Jun Woong, Jun 26, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,077
    Jun Woong
    Jun 26, 2003
  2. Dan Pop
    Replies:
    0
    Views:
    897
    Dan Pop
    Jun 26, 2003
  3. Douglas A. Gwyn

    Re: Override malloc,calloc,realloc and free?

    Douglas A. Gwyn, Jun 26, 2003, in forum: C Programming
    Replies:
    0
    Views:
    747
    Douglas A. Gwyn
    Jun 26, 2003
  4. Dan Pop
    Replies:
    2
    Views:
    2,050
    Jun Woong
    Jun 27, 2003
  5. Jun Woong

    Re: Override malloc,calloc,realloc and free?

    Jun Woong, Jun 27, 2003, in forum: C Programming
    Replies:
    0
    Views:
    840
    Jun Woong
    Jun 27, 2003
Loading...

Share This Page