469,330 Members | 1,271 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,330 developers. It's quick & easy.

Automatic Versus Dynamic

Hello,

I've been trying to optimize a piece of code that executes in 6
milliseconds. From what I have read, dynamically managing memory with
new/malloc and delete/free is less efficient than using the stack to
store variables. Part of my 6 ms code calls delete on class pointers
more than 20000 times. I changed the code to store the class
instances on the stack instead of the heap, so the class's destructor
is called but not delete. Unfortunately, the execution time is still
6 ms.

Does anyone know what is happening? Is automatic storage really more
efficient than dynamic storage?

Any help would be greatly appreciated.

Thanks,
Mike
Jul 9 '08 #1
5 1782
mi************@gmail.com wrote:
Hello,

I've been trying to optimize a piece of code that executes in 6
milliseconds. From what I have read, dynamically managing memory with
new/malloc and delete/free is less efficient than using the stack to
store variables. Part of my 6 ms code calls delete on class pointers
more than 20000 times. I changed the code to store the class
instances on the stack instead of the heap, so the class's destructor
is called but not delete. Unfortunately, the execution time is still
6 ms.
Stack based objects get deleted automatically as they go out of scope.
I think you're still "deleting" everything.
>
Does anyone know what is happening? Is automatic storage really more
efficient than dynamic storage?

Any help would be greatly appreciated.
Memory allocators are quite zippy nowadays.

Have you run a profiler on your code?
Jul 9 '08 #2
On Jul 9, 2:50 am, Michael DOUBEZ <michael.dou...@free.frwrote:
>
Do you mean you call delete on members of a class ? If that's the case,
putting the objects on the stack won't change anything.
I should have added that object allocation is not included in the
timing. I was calling delete, but now the class member is
automatically allocated.

Used to have:
class foo
{
....
bar *b;
};

foo::~foo()
{
delete b;
}

Now I have:
class foo
{
....
bar b;
};

foo::~foo()
{
}

In both cases, bar's destructor is called, but the underlying memory
management is different.
>
The delete is called automatically when the object goes out of scope.
'delete' is not called when an automatically allocated object goes out
of scope; the object's destructor is called.

I need to know exactly what happens when the delete operator runs on a
dynamically allocated object. I've read that the memory is pushed
onto the free list and adjacent free blocks are coalesced into one
larger block. On the other hand, when an object on the stack is
destroyed, the stack pointer is simply adjusted. Therefore, objects
on the stack should take less time to clean up, but that is not
reflected in my timing values. I'd like to know why.

Thanks,
Mike
Jul 9 '08 #3
mi************@gmail.com wrote in news:6809c5b4-c5ed-486a-8839-57d1839da128
@x35g2000hsb.googlegroups.com:

I need to know exactly what happens when the delete operator runs on a
dynamically allocated object. I've read that the memory is pushed
onto the free list and adjacent free blocks are coalesced into one
larger block. On the other hand, when an object on the stack is
destroyed, the stack pointer is simply adjusted. Therefore, objects
on the stack should take less time to clean up, but that is not
reflected in my timing values. I'd like to know why.
Magic. What happens when delete is called is magic. Assuming the standard
new and delete, all you can say is that after delete, the memory that was
deleted has been returned to the free store. Precisely how the free store
is managed is an implementation detail, and you'll have to consult your
compiler/OSes documentation.
Jul 9 '08 #4
mi************@gmail.com wrote:
[..]
I need to know exactly what happens when the delete operator runs on a
dynamically allocated object. I've read that the memory is pushed
onto the free list and adjacent free blocks are coalesced into one
larger block. On the other hand, when an object on the stack is
destroyed, the stack pointer is simply adjusted. Therefore, objects
on the stack should take less time to clean up, but that is not
reflected in my timing values. I'd like to know why.
There is a function called 'deallocation function', which the what the
global operator delete is usually called, I think. The statement with
the 'delete' operator for a single object (not an array) has two steps,
it calls the object's destructor and then calls the deallocation
function. It's a bit simplified, for more read the Standard, [expr.delete].

What the deallocation function does under the covers is
implementation-defined. Whether "the memory is pushed", or "adjacent
blocks are coalesced" is not defined by the language itself. Perhaps
you need to see the documentation for your compiler/library to get a
better idea of what's really going on behind the covers. Of course, you
can also redefine the operators 'new' and 'delete' for your class and
the overloaded 'delete' is going to be called instead of the
'deallocation function' (or, rather, it will be the deallocation
function in that case).

You seem to be saying that you see no difference if the object is
dynamic or automatic. Perhaps your timing mechanism needs to have
higher resolution?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Jul 9 '08 #5
On Jul 9, 5:38 pm, Victor Bazarov <v.Abaza...@comAcast.netwrote:
mike.m.schm...@gmail.com wrote:
[..]
I need to know exactly what happens when the delete operator
runs on a dynamically allocated object. I've read that the
memory is pushed onto the free list and adjacent free blocks
are coalesced into one larger block. On the other hand,
when an object on the stack is destroyed, the stack pointer
is simply adjusted. Therefore, objects on the stack should
take less time to clean up, but that is not reflected in my
timing values. I'd like to know why.
There is a function called 'deallocation function', which the
what the global operator delete is usually called, I think.
The statement with the 'delete' operator for a single object
(not an array) has two steps, it calls the object's destructor
and then calls the deallocation function. It's a bit
simplified, for more read the Standard, [expr.delete].
What the deallocation function does under the covers is
implementation-defined. Whether "the memory is pushed", or
"adjacent blocks are coalesced" is not defined by the language
itself. Perhaps you need to see the documentation for your
compiler/library to get a better idea of what's really going
on behind the covers. Of course, you can also redefine the
operators 'new' and 'delete' for your class and the overloaded
'delete' is going to be called instead of the 'deallocation
function' (or, rather, it will be the deallocation function in
that case).
You seem to be saying that you see no difference if the object
is dynamic or automatic. Perhaps your timing mechanism needs
to have higher resolution?
Or perhaps the cost of dynamic allocation is negligible compared
to other things he's doing. (A single allocation and free are
certainly negligible compared to 6ms.) Or perhaps he's just
encountered a case where allocation is particularly
fast---allocating and freeing the same block over and over, with
no intervening allocations or frees, can be very cheap in some
allocators.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jul 10 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Kevin | last post: by
12 posts views Thread by Christopher J. Bottaro | last post: by
2 posts views Thread by j_mckitrick | last post: by
1 post views Thread by Michael | last post: by
44 posts views Thread by John A. Bailo | last post: by
58 posts views Thread by Jorge Peixoto de Morais Neto | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by Purva khokhar | last post: by
1 post views Thread by haryvincent176 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.