«

Hi,

I have a question on how the size of memory malloc'd affects the
performance of a program. For example, comparing malloc-ing 100 bytes
vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
the former faster than the latter since it allocates a smaller memory
block?

Thank you.

On Sep 29, 6:04 pm, "lancer6...@yahoo.com" <lancer6...@yahoo.com>
wrote:
> Hi,
>
> I have a question on how the size of memory malloc'd affects the
> performance of a program. For example, comparing malloc-ing 100 bytes
> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
> the former faster than the latter since it allocates a smaller memory
> block?
>
> Thank you.

Forgot to say I'm using GCC 4.1.2 on Linux.

On 09/29/10 11:15 PM, wrote:
> On Sep 29, 6:04 pm, "lancer6...@yahoo.com"<lancer6...@yahoo.com>
> wrote:
>> Hi,
>>
>> I have a question on how the size of memory malloc'd affects the
>> performance of a program. For example, comparing malloc-ing 100 bytes
>> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
>> the former faster than the latter since it allocates a smaller memory
>> block?
>>
>> Thank you.
>
> Forgot to say I'm using GCC 4.1.2 on Linux.

If your requirements are that specific, can't you just measure? Several
times, both on quiet and on busy systems (with plenty of memory!).

--
Ian Collins

"" <> writes:

> On Sep 29, 6:04 pm, "lancer6...@yahoo.com" <lancer6...@yahoo.com>
> wrote:
>> I have a question on how the size of memory malloc'd affects the
>> performance of a program. For example, comparing malloc-ing 100 bytes
>> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
>> the former faster than the latter since it allocates a smaller memory
>> block?
<snip>
> Forgot to say I'm using GCC 4.1.2 on Linux.

That's probably not what you want to know! Most Linux systems are set
up in such a way that mallocing 80,000,000 pieces of memory has almost
no effect at all (and the speed will be the same for 100 byte pieces as
it will be for 500 bytes ones). Things will be very different as soon
as you start to use the malloced data and the pattern of usage is likely
to be more significant than the sizes of the individual pieces.

If you design you program with the memory allocation split off cleanly,
you can probably ignore this issue until you have enough of the program
working to be able to do real tests. With a clean interface to the
allocation routines you can then experiment with different strategies.
You might even find that allocating exactly what you need when you need
it is fast enough.

The question as asked is odd because programs normally some specific
amount of memory so to comparison should be between 80,000,000 100-byte
allocations and 16,000,000 500-byte allocations.

--
Ben.

"Ben Bacarisse" <> wrote in message
news:0.685f6175aa61cc1b7869.20100929121528BST.87r5 ...
> "" <> writes:
>
>> On Sep 29, 6:04 pm, "lancer6...@yahoo.com" <lancer6...@yahoo.com>
>> wrote:
>>> I have a question on how the size of memory malloc'd affects the
>>> performance of a program. For example, comparing malloc-ing 100 bytes
>>> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
>>> the former faster than the latter since it allocates a smaller memory
>>> block?

> The question as asked is odd because programs normally some specific
> amount of memory so to comparison should be between 80,000,000 100-byte
> allocations and 16,000,000 500-byte allocations.

Maybe the choice is between a 100-byte and 500-byte data structure.

Usually smaller memory wins, unless it requires extra processing. (And
assuming not all 80 million blocks are allocated at the same time.)

--
Bartc

On 2010-09-29, <> wrote:
> I have a question on how the size of memory malloc'd affects the
> performance of a program. For example, comparing malloc-ing 100 bytes
> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
> the former faster than the latter since it allocates a smaller memory
> block?

Answer: Maybe. One might be faster than the other, or maybe not.

It's not going to be consistent enough for long enough to justify thinking
about it for most real-world cases. Normally when I've seen big shifts in
behavior, they've come up at sizes measured in tens of megabytes; for
instance, one implementation I use switches to a different kind of allocation
entirely at 64-128MB or so.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On Sep 29, 6:04*am, "lancer6...@yahoo.com" <lancer6...@yahoo.com>
wrote:
> Hi,
>
> I have a question on how the size of memory malloc'd affects the
> performance of a program. For example, comparing malloc-ing 100 bytes
> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
> the former faster than the latter since it allocates a smaller memory
> block?

Lots of good answers already. The only thing to add is that there is
no inherent characteristic of common allocation _algorithms_ that will
be affected by the size of of allocated blocks. Rather, the
distribution of sizes and locations of free blocks tend to be the
important independent variables determining the run time of allocation
algorithms.

On Sep 29, 3:04*am, "lancer6...@yahoo.com" <lancer6...@yahoo.com>
wrote:
> Hi,
>
> I have a question on how the size of memory malloc'd affects the
> performance of a program. For example, comparing malloc-ing 100 bytes
> vs 500 bytes of memory, and calling the malloc 80,000,000 times, is
> the former faster than the latter since it allocates a smaller memory
> block?
>
> Thank you.

This is actually more complex than it appears. If you keep the total
amount of memory allocated fixed, and change the size of the
allocations, then the smaller allocations will have many more function
calls. For very small allocations, this overhead dominates, and the
total time taken drops inversely as the size increases.

The complexity comes in because allocators switch between allocation
algorithms at certain sizes. As the block size increases, they need
to worry more about fragmentation and excess memory usage. This
causes them to be slower than the speed-optimized small block case,
and get even slower as the block size increases. For most allocators
that I've measured on Linux, the "fastest" point is around block sizes
of 2^10 bytes plus or minus a few powers of two.

Yet another effect on allocation speed is how optimized they are with
respect to multithreading. If you have more than one thread
allocating and freeing at the same time, then some allocators can be
adversely affected.

Steven