Sign in to follow this  
The C modest god

new/delete

Recommended Posts

Does doing alot of new and delete really have a performance hit? I mean doing new and delete for small amount of memory. After a page has been allocated to the heap, the internal management of the page by libc shouldnt be too much expensive. Maybe only when a new page should be allocated to the heap, but that would happen only if you constantly increase your memory demand, if you allocate and then release memory constantly without increasing the total amount of memory your program need, then there should be any page allocation. What do you think?

Share this post


Link to post
Share on other sites
Yes, allocation and deallocation can have performance penalties. Especially lots of small allocations...this can easily lead to heap fragmentation, which not only increases the cost of allocating new objects, it wastes memory. This means your memory use can grow even though the actual amount of memory used isn't changing. Even without fragmentation, every time you call new it has to hunt down a place to put your object, so it is hardly a trivial operation.

CM

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
Does doing alot of new and delete really have a performance hit?
I mean doing new and delete for small amount of memory.
After a page has been allocated to the heap, the internal management of the page by libc shouldnt be too much expensive.
Maybe only when a new page should be allocated to the heap, but that would happen only if you constantly increase your memory demand, if you allocate and then release memory constantly without increasing the total amount of memory your program need, then there should be any page allocation.

What do you think?


I think your profiler will tell you what you need to know.

I also think that it has been my experience that new and delete can eat huge chunks of CPU time acquiring and releasing locks. When your profiler shows this to be significant, you should look into replacing new with (a) a lock-free allocator of you're in a single-threaded environment, or (b) some alternative design if you're in a threaded environment.

Yes, page allocation is a problem solved long ago. Writing a perfomant general-purpose allocator in the presence of threading is not, not will it be in the future. Some times a specialized tool is what you need.

But again, you will only need to do anything when your profiler tells you you would benefit.

Share this post


Link to post
Share on other sites
Use new and delete for your objects. If the allocation turns out to be a bottleneck, overload the operators to use a pool allocator or a similar contraption.

Share this post


Link to post
Share on other sites
Quote:
Original post by Bregma
Quote:
Original post by The C modest god
Does doing alot of new and delete really have a performance hit?
I mean doing new and delete for small amount of memory.
After a page has been allocated to the heap, the internal management of the page by libc shouldnt be too much expensive.
Maybe only when a new page should be allocated to the heap, but that would happen only if you constantly increase your memory demand, if you allocate and then release memory constantly without increasing the total amount of memory your program need, then there should be any page allocation.

What do you think?


I think your profiler will tell you what you need to know.

I also think that it has been my experience that new and delete can eat huge chunks of CPU time acquiring and releasing locks. When your profiler shows this to be significant, you should look into replacing new with (a) a lock-free allocator of you're in a single-threaded environment, or (b) some alternative design if you're in a threaded environment.

Yes, page allocation is a problem solved long ago. Writing a perfomant general-purpose allocator in the presence of threading is not, not will it be in the future. Some times a specialized tool is what you need.

But again, you will only need to do anything when your profiler tells you you would benefit.

What do you mean by profiler?
What is a lock free allocator?

Share this post


Link to post
Share on other sites
A profiler is something like Intel's VTune or DevPartner Profiler Community Edition. They let you run your program, and then tell you what functions or lines of code were called the most times and took the longest to complete. Without a profiler, optimizations are pretty pointless, as you could spend hours optimizing a function to be 5x as fast, when in reality you only go from 5 to 1 nanosecond, while another function is taking 1000 times as long to complete. So profilers let you know what to optimize.

I'd recomment DevPartner's profiler. The community edition is free, and it's a plugin for Visual Studio, if you have that.

On the original question, new and delete are very common places for performance bottlenecks, particularly if you're doing many new and delete calls (hundreds or thousands per frame). At work, I once saw a loop with a new and delete inside a major loop. I simply moved the new and delete calls outside the loop and improved speed on the process from thirty seconds to about half a second.

Share this post


Link to post
Share on other sites
Quote:
Original post by BeanDog
A profiler is something like Intel's VTune or DevPartner Profiler Community Edition. They let you run your program, and then tell you what functions or lines of code were called the most times and took the longest to complete. Without a profiler, optimizations are pretty pointless, as you could spend hours optimizing a function to be 5x as fast, when in reality you only go from 5 to 1 nanosecond, while another function is taking 1000 times as long to complete. So profilers let you know what to optimize.

I'd recomment DevPartner's profiler. The community edition is free, and it's a plugin for Visual Studio, if you have that.

On the original question, new and delete are very common places for performance bottlenecks, particularly if you're doing many new and delete calls (hundreds or thousands per frame). At work, I once saw a loop with a new and delete inside a major loop. I simply moved the new and delete calls outside the loop and improved speed on the process from thirty seconds to about half a second.

The DevPartner profiler is also for regular unmanged C++? because they say its for all .net managed languages.
Does the free version has all the capabilities in terms of the profiler? and the full version has more things like debugging tools?


Share this post


Link to post
Share on other sites
Take care not to do one of the ridiculous things I've seen people do with new/delete. I.e. allocating and deallocating small buffers inside a function.
Instead of this
void DoSomeThing()
{
int *foobar = new int[3];

// Blah Blah Blah

delete foobar;
}
Do this:
void DoSomeThing()
{
int foobar[3];

// Blah Blah Blah

}

Share this post


Link to post
Share on other sites
Quote:
Original post by The C modest god
The DevPartner profiler is also for regular unmanged C++? because they say its for all .net managed languages.
Does the free version has all the capabilities in terms of the profiler? and the full version has more things like debugging tools?


The free version is good for unmanaged C++, I use it regularly. It installs an extra option in the Tools menu for "Native C++ Instrumentation", which embeds profiling code into your application automatically. In .NET, there's no need for this. The down side is that the instrumented profiling code slows you down a lot, so I usually leave the instrumentation off unless I'm profiling.

The free version does not have all the reporting tools for profiling that the paid version does, but it has plenty for me.

Share this post


Link to post
Share on other sites
Like iMalc said.

Except that between that, the standard library containers (and helpers like std::auto_ptr) and proper use of RAII for your own classes, you should hardly ever actually have to write 'new' or (especially) 'delete'. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this