free() performance question

Discussion in 'C Programming' started by Lianjun Jiang, Jun 28, 2007.

  1. Hi,
    In my code, I need to concat two buffer into one. I take following
    steps:
    1 malloc a new space
    2 copy two buffers over,
    3. and then free the originial two buffers.
    I put timer on each step. And I found that under some stress
    condition(cpu intensive, lots of memory used), the last step took a
    lot more time than step 1 and 2. Did anyone know what could be the
    reason?
     
    Lianjun Jiang, Jun 28, 2007
    #1
    1. Advertising

  2. Lianjun Jiang <> writes:
    > In my code, I need to concat two buffer into one. I take following
    > steps:
    > 1 malloc a new space
    > 2 copy two buffers over,
    > 3. and then free the originial two buffers.
    > I put timer on each step. And I found that under some stress
    > condition(cpu intensive, lots of memory used), the last step took a
    > lot more time than step 1 and 2. Did anyone know what could be the
    > reason?


    It's extremely system-specific.

    The C standard says absolutely nothing about the performance of malloc
    and free (or of anything else, for that matter).

    malloc and free have to manipulate whatever internal data structures
    the implementation uses for memory allocation. It's possible that
    malloc() merely has to find the first available free chunk of at least
    the requested size, but free() has to do considerable work to
    rearrange things (merging adjacent free chunks, updating statistics,
    whatever) for future allocations. But that's pure speculation on my
    part.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 28, 2007
    #2
    1. Advertising

  3. Lianjun  Jiang

    pandaj Guest

    On Jun 27, 4:27 pm, Keith Thompson <> wrote:
    > Lianjun Jiang <> writes:
    >
    > > In my code, I need to concat two buffer into one. I take following
    > > steps:
    > > 1 malloc a new space
    > > 2 copy two buffers over,
    > > 3. and then free the originial two buffers.
    > > I put timer on each step. And I found that under some stress
    > > condition(cpu intensive, lots of memory used), the last step took a
    > > lot more time than step 1 and 2. Did anyone know what could be the
    > > reason?

    >
    > It's extremely system-specific.
    >
    > The C standard says absolutely nothing about the performance of malloc
    > and free (or of anything else, for that matter).
    >
    > malloc and free have to manipulate whatever internal data structures
    > the implementation uses for memory allocation. It's possible that
    > malloc() merely has to find the first available free chunk of at least
    > the requested size, but free() has to do considerable work to
    > rearrange things (merging adjacent free chunks, updating statistics,
    > whatever) for future allocations. But that's pure speculation on my
    > part.
    >
    > --
    > Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    > San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    > "We must do something. This is something. Therefore, we must do this."
    > -- Antony Jay and Jonathan Lynn, "Yes Minister"


    I'm using gcc-3.0.4, is there some documentation to check its "free"
    implementation? Also this program is a multithread program. The buffer
    freed in one thread is like to be allocated by another thread. Does it
    matter?

    Thanks
     
    pandaj, Jun 28, 2007
    #3
  4. Lianjun  Jiang

    pandaj Guest

    On Jun 27, 4:30 pm, pandaj <> wrote:
    > On Jun 27, 4:27 pm, Keith Thompson <> wrote:
    >
    >
    >
    > > Lianjun Jiang <> writes:

    >
    > > > In my code, I need to concat two buffer into one. I take following
    > > > steps:
    > > > 1 malloc a new space
    > > > 2 copy two buffers over,
    > > > 3. and then free the originial two buffers.
    > > > I put timer on each step. And I found that under some stress
    > > > condition(cpu intensive, lots of memory used), the last step took a
    > > > lot more time than step 1 and 2. Did anyone know what could be the
    > > > reason?

    >
    > > It's extremely system-specific.

    >
    > > The C standard says absolutely nothing about the performance of malloc
    > > and free (or of anything else, for that matter).

    >
    > > malloc and free have to manipulate whatever internal data structures
    > > the implementation uses for memory allocation. It's possible that
    > > malloc() merely has to find the first available free chunk of at least
    > > the requested size, but free() has to do considerable work to
    > > rearrange things (merging adjacent free chunks, updating statistics,
    > > whatever) for future allocations. But that's pure speculation on my
    > > part.

    >
    > > --
    > > Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    > > San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    > > "We must do something. This is something. Therefore, we must do this."
    > > -- Antony Jay and Jonathan Lynn, "Yes Minister"

    >
    > I'm using gcc-3.0.4, is there some documentation to check its "free"
    > implementation? Also this program is a multithread program. The buffer
    > freed in one thread is like to be allocated by another thread. Does it
    > matter?
    >
    > Thanks



    I did the following test:

    struct my_buf *tmp1, *tmp2;
    {
    MY_TIMER(timer1);

    tmp1 = (struct my_buf*) malloc(sizeof(p1[0])*n1);
    tmp2 = (struct my_buf*) malloc(sizeof(p2[0])*n2);
    memcpy(tmp1, p1, sizeof(p1[0])*n1);
    memcpy(tmp2, p2, sizeof(p2[0])*n2);
    }
    {
    MY_TIMER(timer2);
    free(p1);
    free(p2);
    }
    {
    MY_TIMER(timer3);
    free(tmp1);
    free(tmp2);
    }

    p1 and p2 are buffers allocated elsewhere and passed into the
    function. In one test, timer1 report 0.003 ms, timer2 report 3.1 ms
    and timer3 report 0.18 ms. So free definitely doing more work than
    malloc in my case, but I still don't know why the free of foreign
    buffers could take so much time than free "local" buffers.

    Thanks
     
    pandaj, Jun 28, 2007
    #4
  5. On 28 Jun, 00:03, Lianjun Jiang <> wrote:
    > Hi,
    > In my code, I need to concat two buffer into one. I take following
    > steps:
    > 1 malloc a new space
    > 2 copy two buffers over,
    > 3. and then free the originial two buffers.
    > I put timer on each step. And I found that under some stress
    > condition(cpu intensive, lots of memory used), the last step took a
    > lot more time than step 1 and 2. Did anyone know what could be the
    > reason?


    I have no idea why free takes a long time but one suggestion
    is that you use realloc to make the first buffer large
    enough to also fit the second buffer , then add the
    second buffer to the end of the first and free the second.
    Perhaps this will run faster.

    Are you sure that the timer you're using is reliable ?
     
    Spiros Bousbouras, Jun 28, 2007
    #5
  6. Lianjun  Jiang

    pandaj Guest

    On Jun 27, 4:58 pm, Spiros Bousbouras <> wrote:
    > On 28 Jun, 00:03, Lianjun Jiang <> wrote:
    >
    > > Hi,
    > > In my code, I need to concat two buffer into one. I take following
    > > steps:
    > > 1 malloc a new space
    > > 2 copy two buffers over,
    > > 3. and then free the originial two buffers.
    > > I put timer on each step. And I found that under some stress
    > > condition(cpu intensive, lots of memory used), the last step took a
    > > lot more time than step 1 and 2. Did anyone know what could be the
    > > reason?

    >
    > I have no idea why free takes a long time but one suggestion
    > is that you use realloc to make the first buffer large
    > enough to also fit the second buffer , then add the
    > second buffer to the end of the first and free the second.
    > Perhaps this will run faster.
    >
    > Are you sure that the timer you're using is reliable ?


    At first, my implementation is using realloc, and then realloc takes
    similar time as free. I think that is because realloc need one free
    call, too. So I used current approach, and kind of verify it is the
    free that slow down realloc.

    For the timers, it at least provides very consistent result.
     
    pandaj, Jun 28, 2007
    #6
  7. pandaj <> writes:
    > On Jun 27, 4:27 pm, Keith Thompson <> wrote:
    >> Lianjun Jiang <> writes:
    >>
    >> > In my code, I need to concat two buffer into one. I take following
    >> > steps:
    >> > 1 malloc a new space
    >> > 2 copy two buffers over,
    >> > 3. and then free the originial two buffers.
    >> > I put timer on each step. And I found that under some stress
    >> > condition(cpu intensive, lots of memory used), the last step took a
    >> > lot more time than step 1 and 2. Did anyone know what could be the
    >> > reason?

    >>
    >> It's extremely system-specific.
    >>
    >> The C standard says absolutely nothing about the performance of malloc
    >> and free (or of anything else, for that matter).
    >>
    >> malloc and free have to manipulate whatever internal data structures
    >> the implementation uses for memory allocation. It's possible that
    >> malloc() merely has to find the first available free chunk of at least
    >> the requested size, but free() has to do considerable work to
    >> rearrange things (merging adjacent free chunks, updating statistics,
    >> whatever) for future allocations. But that's pure speculation on my
    >> part.


    Please don't quote signatures. When you post a followup, quote just
    enough of the previous article so your followup makes sense.

    > I'm using gcc-3.0.4, is there some documentation to check its "free"
    > implementation? Also this program is a multithread program. The buffer
    > freed in one thread is like to be allocated by another thread. Does it
    > matter?


    <OT>gcc has no free implementation; free is provided by the runtime
    library, not the compiler.</OT>

    There may or may not be documentation for your runtime library's
    implementation of malloc and free. Multithreading might affect the
    behavior of malloc and free, at least internally, but the standard C
    language doesn't support multithreading.

    Your question are about your specific implementation. You'll need to
    find a newsgroup or other forum that discusses your implementation.
    This newsgroup discusses the C language as defined by the standard.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 28, 2007
    #7
  8. Lianjun  Jiang

    Guest

    On Jun 27, 4:03 pm, Lianjun Jiang <> wrote:
    > In my code, I need to concat two buffer into one. I take following
    > steps:
    > 1 malloc a new space
    > 2 copy two buffers over,
    > 3. and then free the originial two buffers.
    > I put timer on each step. And I found that under some stress
    > condition(cpu intensive, lots of memory used), the last step took a
    > lot more time than step 1 and 2. Did anyone know what could be the
    > reason?


    In balanced heap implementations, the cost of free() and malloc()
    should be *roughly* the same. free() needs to merge the memory with
    adjacent free buffers if possible, and then update the new free
    buffers relative to whatever structures they exist in to assist the
    malloc() function to find them quickly.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Jun 28, 2007
    #8
  9. Lianjun  Jiang

    CBFalconer Guest

    Lianjun Jiang wrote:
    >
    > In my code, I need to concat two buffer into one. I take following
    > steps:
    > 1 malloc a new space
    > 2 copy two buffers over,
    > 3. and then free the originial two buffers.
    > I put timer on each step. And I found that under some stress
    > condition(cpu intensive, lots of memory used), the last step took
    > a lot more time than step 1 and 2. Did anyone know what could be
    > the reason?


    Yes. It usually depends on the number of malloced pieces in effect
    at the time and the effort required to detect and join them. I
    wrote nmalloc to avoid it (and a few other problems). See:

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

    for an (almost) standard C implementation for DJGPP and others.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 28, 2007
    #9
  10. Lianjun  Jiang

    CBFalconer Guest

    wrote:
    > Lianjun Jiang <> wrote:
    >
    >> In my code, I need to concat two buffer into one. I take following
    >> steps:
    >> 1 malloc a new space
    >> 2 copy two buffers over,
    >> 3. and then free the originial two buffers.
    >> I put timer on each step. And I found that under some stress
    >> condition(cpu intensive, lots of memory used), the last step took a
    >> lot more time than step 1 and 2. Did anyone know what could be the
    >> reason?

    >
    > In balanced heap implementations, the cost of free() and malloc()
    > should be *roughly* the same. free() needs to merge the memory with
    > adjacent free buffers if possible, and then update the new free
    > buffers relative to whatever structures they exist in to assist the
    > malloc() function to find them quickly.


    I don't know what you mean by 'balanced heap', but in general the
    cause is the excessive searching for adjacent blocks to merge
    during the free operation. This is often an O(n) operation. In
    nmalloc, it is cut to O(1).

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 28, 2007
    #10
  11. Lianjun  Jiang

    Barry Guest

    "CBFalconer" <> wrote in message
    news:...
    > Lianjun Jiang wrote:
    >>
    >> In my code, I need to concat two buffer into one. I take following
    >> steps:
    >> 1 malloc a new space
    >> 2 copy two buffers over,
    >> 3. and then free the originial two buffers.
    >> I put timer on each step. And I found that under some stress
    >> condition(cpu intensive, lots of memory used), the last step took
    >> a lot more time than step 1 and 2. Did anyone know what could be
    >> the reason?

    >
    > Yes. It usually depends on the number of malloced pieces in effect
    > at the time and the effort required to detect and join them. I
    > wrote nmalloc to avoid it (and a few other problems). See:
    >
    > <http://cbfalconer.home.att.net/download/>
    >
    > for an (almost) standard C implementation for DJGPP and others.
    >


    Although in most cases I agree with you, how do you find an
    almost because I wrote it, appropriate for clc?
     
    Barry, Jun 28, 2007
    #11
  12. Lianjun  Jiang

    jacob navia Guest

    Barry wrote:
    > "CBFalconer" <> wrote in message
    > news:...
    >> Lianjun Jiang wrote:
    >>> In my code, I need to concat two buffer into one. I take following
    >>> steps:
    >>> 1 malloc a new space
    >>> 2 copy two buffers over,
    >>> 3. and then free the originial two buffers.
    >>> I put timer on each step. And I found that under some stress
    >>> condition(cpu intensive, lots of memory used), the last step took
    >>> a lot more time than step 1 and 2. Did anyone know what could be
    >>> the reason?

    >> Yes. It usually depends on the number of malloced pieces in effect
    >> at the time and the effort required to detect and join them. I
    >> wrote nmalloc to avoid it (and a few other problems). See:
    >>
    >> <http://cbfalconer.home.att.net/download/>
    >>
    >> for an (almost) standard C implementation for DJGPP and others.
    >>

    >
    > Although in most cases I agree with you, how do you find an
    > almost because I wrote it, appropriate for clc?
    >
    >


    Can you explain what's wrong with the message?
    Or you think it is forbidden to speak about what one's writes
    in this newsgroup?

    jacob
     
    jacob navia, Jun 28, 2007
    #12
  13. Lianjun  Jiang

    Barry Guest

    "jacob navia" <> wrote in message
    news:46833ba4$0$5083$...
    > Barry wrote:
    >> "CBFalconer" <> wrote in message
    >> news:...
    >>> Lianjun Jiang wrote:
    >>>> In my code, I need to concat two buffer into one. I take following
    >>>> steps:
    >>>> 1 malloc a new space
    >>>> 2 copy two buffers over,
    >>>> 3. and then free the originial two buffers.
    >>>> I put timer on each step. And I found that under some stress
    >>>> condition(cpu intensive, lots of memory used), the last step took
    >>>> a lot more time than step 1 and 2. Did anyone know what could be
    >>>> the reason?
    >>> Yes. It usually depends on the number of malloced pieces in effect
    >>> at the time and the effort required to detect and join them. I
    >>> wrote nmalloc to avoid it (and a few other problems). See:
    >>>
    >>> <http://cbfalconer.home.att.net/download/>
    >>>
    >>> for an (almost) standard C implementation for DJGPP and others.
    >>>

    >>
    >> Although in most cases I agree with you, how do you find an
    >> almost because I wrote it, appropriate for clc?

    >
    > Can you explain what's wrong with the message?
    > Or you think it is forbidden to speak about what one's writes
    > in this newsgroup?
    >
    > jacob


    I wrote my response in simple English. What part confuses you?
     
    Barry, Jun 28, 2007
    #13
  14. Lianjun  Jiang

    jacob navia Guest

    Barry wrote:
    > "jacob navia" <> wrote in message
    > news:46833ba4$0$5083$...
    >> Barry wrote:
    >>> "CBFalconer" <> wrote in message
    >>> news:...
    >>>> Lianjun Jiang wrote:
    >>>>> In my code, I need to concat two buffer into one. I take following
    >>>>> steps:
    >>>>> 1 malloc a new space
    >>>>> 2 copy two buffers over,
    >>>>> 3. and then free the originial two buffers.
    >>>>> I put timer on each step. And I found that under some stress
    >>>>> condition(cpu intensive, lots of memory used), the last step took
    >>>>> a lot more time than step 1 and 2. Did anyone know what could be
    >>>>> the reason?
    >>>> Yes. It usually depends on the number of malloced pieces in effect
    >>>> at the time and the effort required to detect and join them. I
    >>>> wrote nmalloc to avoid it (and a few other problems). See:
    >>>>
    >>>> <http://cbfalconer.home.att.net/download/>
    >>>>
    >>>> for an (almost) standard C implementation for DJGPP and others.
    >>>>
    >>> Although in most cases I agree with you, how do you find an
    >>> almost because I wrote it, appropriate for clc?

    >> Can you explain what's wrong with the message?
    >> Or you think it is forbidden to speak about what one's writes
    >> in this newsgroup?
    >>
    >> jacob

    >
    > I wrote my response in simple English. What part confuses you?
    >
    >


    You wrote:

    "Although in most cases I agree with you, how do you find an
    almost because I wrote it, appropriate for clc?"

    Parse error. "How do you find an almost" ???
    Something is missing I would say.
     
    jacob navia, Jun 28, 2007
    #14
  15. Lianjun  Jiang

    Barry Guest

    "jacob navia" <> wrote in message
    news:4683ad05$0$25952$...
    > Barry wrote:
    >> "jacob navia" <> wrote in message
    >> news:46833ba4$0$5083$...
    >>> Barry wrote:
    >>>> "CBFalconer" <> wrote in message
    >>>> news:...
    >>>>> Lianjun Jiang wrote:
    >>>>>> In my code, I need to concat two buffer into one. I take following
    >>>>>> steps:
    >>>>>> 1 malloc a new space
    >>>>>> 2 copy two buffers over,
    >>>>>> 3. and then free the originial two buffers.
    >>>>>> I put timer on each step. And I found that under some stress
    >>>>>> condition(cpu intensive, lots of memory used), the last step took
    >>>>>> a lot more time than step 1 and 2. Did anyone know what could be
    >>>>>> the reason?
    >>>>> Yes. It usually depends on the number of malloced pieces in effect
    >>>>> at the time and the effort required to detect and join them. I
    >>>>> wrote nmalloc to avoid it (and a few other problems). See:
    >>>>>
    >>>>> <http://cbfalconer.home.att.net/download/>
    >>>>>
    >>>>> for an (almost) standard C implementation for DJGPP and others.
    >>>>>
    >>>> Although in most cases I agree with you, how do you find an
    >>>> almost because I wrote it, appropriate for clc?
    >>> Can you explain what's wrong with the message?
    >>> Or you think it is forbidden to speak about what one's writes
    >>> in this newsgroup?
    >>>
    >>> jacob

    >>
    >> I wrote my response in simple English. What part confuses you?

    >
    > You wrote:
    >
    > "Although in most cases I agree with you, how do you find an
    > almost because I wrote it, appropriate for clc?"
    >
    > Parse error. "How do you find an almost" ???
    > Something is missing I would say.


    "How do you find an almost," is not what it says. Had I written:
    How do you find a purple polka dot elephant in a bowl of cherries?
    Would you ask how do you find a purple?
     
    Barry, Jun 28, 2007
    #15
  16. In article <>,
    Barry <> wrote:

    >>> I wrote my response in simple English. What part confuses you?


    >> You wrote:
    >>
    >> "Although in most cases I agree with you, how do you find an
    >> almost because I wrote it, appropriate for clc?"
    >>
    >> Parse error. "How do you find an almost" ???
    >> Something is missing I would say.


    >"How do you find an almost," is not what it says. Had I written:
    >How do you find a purple polka dot elephant in a bowl of cherries?
    >Would you ask how do you find a purple?


    I'm a native speaker of English, and I can't make any sense of your
    sentence.

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
     
    Richard Tobin, Jun 28, 2007
    #16
  17. Lianjun  Jiang

    Richard Bos Guest

    (Richard Tobin) wrote:

    > In article <>,
    > Barry <> wrote:
    >
    > >>> I wrote my response in simple English. What part confuses you?

    >
    > >> You wrote:
    > >>
    > >> "Although in most cases I agree with you, how do you find an
    > >> almost because I wrote it, appropriate for clc?"
    > >>
    > >> Parse error. "How do you find an almost" ???
    > >> Something is missing I would say.

    >
    > >"How do you find an almost," is not what it says. Had I written:
    > >How do you find a purple polka dot elephant in a bowl of cherries?
    > >Would you ask how do you find a purple?

    >
    > I'm a native speaker of English, and I can't make any sense of your
    > sentence.


    I'm not a native speaker of English, and I find that sentence completely
    understandable provided it is not ripped cruelly out of context.

    Richard
     
    Richard Bos, Jun 28, 2007
    #17
  18. Lianjun  Jiang

    CBFalconer Guest

    Barry wrote:
    > "CBFalconer" <> wrote in message
    >

    .... snip ...
    >>
    >> Yes. It usually depends on the number of malloced pieces in effect
    >> at the time and the effort required to detect and join them. I
    >> wrote nmalloc to avoid it (and a few other problems). See:
    >>
    >> <http://cbfalconer.home.att.net/download/>
    >>
    >> for an (almost) standard C implementation for DJGPP and others.

    >
    > Although in most cases I agree with you, how do you find an
    > almost because I wrote it, appropriate for clc?


    Please attempt to write a fully standard general malloc package.
    Can't be done. That is one reason it is part of the
    implementation.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 28, 2007
    #18
  19. Lianjun  Jiang

    CBFalconer Guest

    Richard Tobin wrote:
    > Barry <> wrote:
    >
    >>>> I wrote my response in simple English. What part confuses you?

    >
    >>> You wrote:
    >>>
    >>> "Although in most cases I agree with you, how do you find an
    >>> almost because I wrote it, appropriate for clc?"
    >>>
    >>> Parse error. "How do you find an almost" ???
    >>> Something is missing I would say.

    >
    >> "How do you find an almost," is not what it says. Had I written:
    >> How do you find a purple polka dot elephant in a bowl of cherries?
    >> Would you ask how do you find a purple?

    >
    > I'm a native speaker of English, and I can't make any sense of your
    > sentence.


    I am also (a native speaker), yet I can make sense out of it. It
    is an effort, but possible.

    BTW someone has been grossly careless in snipping attributions for
    quoted material.

    --
    <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
    <http://www.securityfocus.com/columnists/423>
    <http://www.aaxnet.com/editor/edit043.html>
    cbfalconer at maineline dot net



    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Jun 28, 2007
    #19
  20. Lianjun  Jiang

    Barry Guest

    "CBFalconer" <> wrote in message
    news:...
    > Barry wrote:
    >> "CBFalconer" <> wrote in message
    >>

    > ... snip ...
    >>>
    >>> Yes. It usually depends on the number of malloced pieces in effect
    >>> at the time and the effort required to detect and join them. I
    >>> wrote nmalloc to avoid it (and a few other problems). See:
    >>>
    >>> <http://cbfalconer.home.att.net/download/>
    >>>
    >>> for an (almost) standard C implementation for DJGPP and others.

    >>
    >> Although in most cases I agree with you, how do you find an
    >> almost because I wrote it, appropriate for clc?

    >
    > Please attempt to write a fully standard general malloc package.
    > Can't be done. That is one reason it is part of the
    > implementation.
    >


    Chuck, the post was partially in gest because you are typically the
    first person to point out off topic posts. I didn't expect it to be a big
    deal :).
     
    Barry, Jun 28, 2007
    #20
    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. jm
    Replies:
    1
    Views:
    538
    alien2_51
    Dec 12, 2003
  2. Arsalan Ahmad
    Replies:
    0
    Views:
    454
    Arsalan Ahmad
    May 23, 2006
  3. george
    Replies:
    0
    Views:
    1,196
    george
    Aug 29, 2008
  4. mohammed_a_o
    Replies:
    0
    Views:
    319
    mohammed_a_o
    Nov 30, 2010
  5. Software Engineer
    Replies:
    0
    Views:
    368
    Software Engineer
    Jun 10, 2011
Loading...

Share This Page