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

mike.m.schmidt@gmail.com wrote:Stack based objects get deleted automatically as they go out of scope.
I think you're still "deleting" everything.
Memory allocators are quite zippy nowadays.

Have you run a profiler on your code?

On Jul 9, 2:50 am, Michael DOUBEZ <michael.dou...@free.frwrote:
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.
'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

mike.m.schmidt@gmail.com wrote in news:6809c5b4-c5ed-486a-8839-57d1839da128
@x35g2000hsb.googlegroups.com:

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.

mike.m.schmidt@gmail.com wrote: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

On Jul 9, 5:38 pm, Victor Bazarov <v.Abaza...@comAcast.netwrote: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:james.kanze@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