Hi Folks,

I just had the following idea for opertor new and delete
(I am sure I am not the first one, haven't seen it
so far though):

class A
{
std::vector< intsomeData;

static std::stack used;

public:
static void * operator new (size_t size);
static void operator delete (void *p, size_t size);
};

void* A::operator new(size_t sz)
{
void* res;
if( used.size() 0)
{
res = used.back();
used.pop();
return res;
}

return ::new( sz);
}

void A::operator delete (void *p, size_t sz)
{
someData.clear();
used.push( p);
}

If there are a lot of instances of A to be allocated and freed all the
time,
could (would) this result in a performance gain compared to
the standard new/delete operator as system calls are avoided in most
cases?
Of course it is obvious that there is a certain memory overhead (for
the stack and as all As are never freed), but it looks to me that this
is a very easy way to gain a lot of performance potentially. Am I
missing something?

<cppquester@googlemail.comwrote in message
news:1188220750.006159.197410@r29g2000hsg.googlegr oups.com...

Hi Folks,
>
I just had the following idea for opertor new and delete
(I am sure I am not the first one, haven't seen it
so far though):

[code snipped]

void* A::operator new(size_t sz)
{
void* res;
if( used.size() 0)
{
res = used.back();

Don't you mean used.top()?

used.pop();
return res;
}

[code snipped]

If there are a lot of instances of A to be allocated and freed all the
time,
could (would) this result in a performance gain compared to
the standard new/delete operator as system calls are avoided in most
cases?

One obvious thing that you should gain is the protection from memory
fragmentation (which is really a big performance gain), the same method can
be (and is) implemented using placement new

Abdo Haji-Ali
Programmer
In|Framez

cppquester@googlemail.com wrote:

I just had the following idea for opertor new and delete
(I am sure I am not the first one, haven't seen it
so far though):
>
class A
{
std::vector< intsomeData;
>
static std::stack used;
>
public:
static void * operator new (size_t size);
static void operator delete (void *p, size_t size);
};
>
void* A::operator new(size_t sz)
{
void* res;
if( used.size() 0)
{
res = used.back();
used.pop();
return res;
}
>
return ::new( sz);
}
>
void A::operator delete (void *p, size_t sz)
{
someData.clear();
used.push( p);
}
>
If there are a lot of instances of A to be allocated and freed all the
time,
could (would) this result in a performance gain compared to
the standard new/delete operator as system calls are avoided in most
cases?
Of course it is obvious that there is a certain memory overhead (for
the stack and as all As are never freed), but it looks to me that this
is a very easy way to gain a lot of performance potentially. Am I
missing something?

The idea, as I understand it, is not to deallocate the last "freed"
instance[s] but to reuse it. Seems nice to have the freeing delayed,
and that's essentially what Boost's pooled memory manager does. Their
idea is not to deallocate and not to reuse, but instead just keep
giving you new pieces and deallocate them all at once at the end, when
you don't need any of them any more.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

I just had the following idea for opertor new and delete

[code snipped]

>
Don't you mean used.top()?

yes.

used.pop();

>
[code snipped]
>

>
One obvious thing that you should gain is the protection from memory
fragmentation (which is really a big performance gain), the same method can
be (and is) implemented using placement new

So my suggestions will lead to fragmentation? But still better than
standard new, isn't it?
Do you have a link to a aolution with placement new?

<cppquester@googlemail.comwrote in message
news:1188221763.454056.176450@w3g2000hsg.googlegro ups.com...

>
So my suggestions will lead to fragmentation? But still better than
standard new, isn't it?
Do you have a link to a aolution with placement new?

On the contrary, what I meant is that the main advantage of a memory pool
(something like what you're doing) IS the *protection* from memory
fragmentation.
For samples, google for "C++ memory pool". This should return a few hundred
of thousands results :)

Abdo Haji-Ali
In|Framez
Programmer

Thanks for your reply (same to all other repliers as well!)

The general idea is called a free-list or, with more sophisticated
management, a cache. And what you're missing is, first, that std::stack
itself uses dynamic allocation,

so what?
For me only performance gain is what counts.
(plus I might use a std::vetor with reserve() in the end)

and second, that in operator delete you
don't have access to instance member data (the instance has already been
destroyed),

Ok.

and third, that a free-list is based on a certain usage
pattern (otherwise it just adds overhead),

As I said, frequent allocation/deallocation (no persistent objects).

and fourth, that defining
operator new and operator delete is very costly in that it prohibits
other possibly more important usages of that mechanism,

Don't get this one: Better no improvement than a reasonable one just
because there is a possible even better one (which then might never be
done in the end because it is way more complicated)?

and fifth, that
it's generally not a good idea to do micro-optimization. In short don't
do it, or at least, don't do it yet (for optimization, first measure!).

I did some. Much of the time is indeed spend on operator new/delete.
(But before actually implementing my idea I thought it is wise to get
some
advice to maybe even make it better - or let it even be if I will be
conviced that the idea wasn't that good in the end).

On Aug 27, 3:33 pm, "Victor Bazarov" <v.Abaza...@comAcast.netwrote:

cppques...@googlemail.com wrote:

>

>

>

>

>

>

>

>
The idea, as I understand it, is not to deallocate the last "freed"
instance[s] but to reuse it. Seems nice to have the freeing delayed,
and that's essentially what Boost's pooled memory manager does. Their
idea is not to deallocate and not to reuse, but instead just keep
giving you new pieces and deallocate them all at once at the end, when
you don't need any of them any more.

I think I cannot use a pool here because I do not know the peak memory
amount used. Some objects might have a very short life span, others
might
exist almost for the whole runtime.

On 2007-08-27 16:06, cppquester@googlemail.com wrote:

Thanks for your reply (same to all other repliers as well!)
>

>
so what?
For me only performance gain is what counts.
(plus I might use a std::vetor with reserve() in the end)

Even vector with reserve() is not safe, should you ever over-allocate it
will re-allocate and you're in deep shit, so to speak. To do it
correctly you must allocate raw memory and do the book-keeping yourself.

One way to do it would be to allocate chunks of data sized to be a
multiple of the size of the objects, say 10 to 50. Then you keep track
of how many objects you have in each chunk. When all are full you
allocate a new one and start filling it. The idea is that when you start
deallocating the objects you'll end up with empty chunks which can then
be deallocated.

For some usage patterns this will end up with lots of chunks with one
object in each, but never more chunks than needed to hold the maximum
number of objects used.

--
Erik Wikström

"Alf P. Steinbach" <alfps@start.nowrote in news:13d5m5fsfp1laf5
@corp.supernews.com:

>
Considering that original code would not compile, it isn't necessarily
bad to introduce additional undefined behavior.
>
However, the OP and other readers may get the impression that the above
would be a good idea.
>
So, to correct that impression: it's just Undefined Behavior, the object
has already been destroyed.
>

Good point, I was focusing too much on the OP's code and not enough on what
was actually happening.

joe