«

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

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

"Rahul Gandhi" <> wrote in message
news: om...
> 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

(Rahul Gandhi) wrote in message news:<. com>...
> 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.

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).

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!

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

>"Rahul Gandhi" <> wrote in message
>news:. com...
>> 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

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:

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.

"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.