[Boost-users] boost and memory allocations (signals and others)

From: Frank Maddin (frankmad_at_[hidden])
Date: 2004-12-13 12:01:01

We've been thinking about using certain boost functionality on a
project.  We were trying to keep the number of allocations down.

 

An engineer did some testing on signals and their usage of memory and
found that there was a surprising number of allocation related things
were happening.  Even sending a signal did allocation ops.

 

If developers want to reduce allocation overhead, do they use memory
pools or some other solution?

 

Is there a pattern of large numbers of small allocations across the lib?
For things like the boost's smart pointers also?

 

Below is a description of the test.

 

Thanks,

-fm

 

------------

 

Memory Usage

 

I ran a simple test to see how much memory is being used

 

            struct Hello

            {

                        void operator (int year)

                        {

                                    printf("Year = %d\n",year);

                        }

            };

 

            void Test ()

            {

                        Hello hello;

                        boost::signal< void(int) > sig;

                        sig.connect( hello );

                        sig( 1968 );

            }

 

Note: I used _CrtSetAllocHook to monitor the memory usage...

 

Results:

 

sizeof( sig ) = 24 bytes

 

but the default constructor does a surprising amount of dynamic
allocation (for an empty list)

 

            calls malloc or free 51 times

 

allocates 277 bytes in 13 blocks (not including heap overhead)

 

so the actual size is more like 24 + 277 + 13*8 = 405 byes 

 

a call to connect does 26 alloc-operations... resulting in 133 bytes in
8 blocks

 

a call to send a signal does 78 alloc-operations... resulting in 0 bytes
in 0 blocks

 

...

 

My tests were debug builds... but I looked at the calls and the library
just calls new a lot... there seems to be a pattern of having empty
wrapper classes where the constructor dynamically allocates the actual
implementation...