Heap efficiency?

[_uj]

I wonder how efficient is the C++ heap generally?

Say I would like to create in the order of 1 million quite small objects quite frequently. Is the ordinary C++ heap fit to handle this, or will it be like wading in a tar pit?

I know I should measure and see if it's a performance bottleneck in my specific program, but I'm looking for a more general assessment. If you're programming in the OO style is the C++ heap likely to become a bottleneck and you should seek aid in a specialized object allocator or even a garbage collector?

[Paul McKenzie]

I wonder how efficient is the C++ heap generally?

This all depends on the compiler and implementation.

Regards,

Paul McKenzie

[TheCPUWizard]

With *proper design* heap performance should never be an issue.

For some recommendations on heaps and small object allocation see here

ps: Paul 100% correct in that it WILL vary, and MEASUREMENT against a DEFINED REQUIREMENT is key to any analysis of performance.

[_uj]

This all depends on the compiler and implementation.

Regards,

Paul McKenzie

Do you mean that with SOME compiler and with SOME object usage this ceases to be a problem?

Then it would be interesting to hear your advice as to WHAT compiler one should use and to HOW one's objects should be managed.

[Paul McKenzie]

Do you mean that with SOME compiler and with SOME object usage this ceases to be a problem?

What I'm saying is that the heap manager is written by the compiler vendor. There are many ways to write a heap manager -- look up best fit, first fit, etc.

Then it would be interesting to hear your advice as to WHAT compiler one should use and to HOW ones objects should be managed.

That is your research project.

Regards,

Paul McKenzie

[_uj]

With *proper design* heap performance should never be an issue.

Do you mean C++ programs should better be designed to avoid heap allocations?

[_uj]

What I'm saying is that the heap manager is written by the compiler vendor. There are many ways to write a heap manager -- look up best fit, first fit, etc.
That is your research project.

No it's not my research project. I've done my research (test me if you like).

What I'm asking is if you have something to contribute on this matter (besides the general bullshit)?

[Lindley]

Do you mean C++ programs should better be designed to avoid heap allocations?

Certainly they should be designed to avoid overusing heap allocations. Often you can write lots of code without ever using a new call. If heap allocation is done internally by an STL container or something don't worry about it, though.

[Paul McKenzie]

What I'm asking is if you have something to contribute on this matter

And I did just that. Heap managers performance and efficiency depends on the compiler's implementation.

Is the ordinary C++ heap

That's my point -- there is no such thing as an "ordinary C++ heap".

I don't know how old you are, but in the days when there were compiler wars between Microsoft, Borland, Watcom, etc. the efficiency of the heap was a major selling point, emphasizing the fact that heap performance was (and is) highly dependent on the implementation.

That is why I stated you do the research on what compiler has to offer in terms of heap performance. I am not paid to do this.

Regards,

Paul McKenzie

[_uj]

Certainly they should be designed to avoid overusing heap allocations. Often you can write lots of code without ever using a new call. If heap allocation is done internally by an STL container or something don't worry about it, though.

What exactly do you mean by "designed to avoid overusing heap allocations"?

To me it suggests you consider possible heap allocations an important design criterion. Do you?

[TheCPUWizard]

Do you mean C++ programs should better be designed to avoid heap allocations?

I amn saying that any piece of software can be effectively used or it can be mis-used. he book I referenced contains published,proven and accepts techniques to be effective.

ps: That is only one section of this book, which I firmly believe should be read and understood by every serious C++ programmer [typically after reading all of Scott Meyers' books]. The only caution I give is the intermediate programmers should wear a helmet while reading as this will minimze the mess should their head literally explode (the more advanced programmer may simply need a large bottle of extra strength headache medicine.

[_uj]

Well, the question of the efficiency/ineffÃ*ciency of the C++ heap definately deserves a discussion.

For the time being, extensive usage of the C++ heap, is a big "no no" right?

[TheCPUWizard]

Well, the question of the efficiency/ineffÃ*ciency of the C++ heap definately deserves a discussion.

For the time being, extensive usage of the C++ heap, is a big "no no" right?

Not at all, at least not in any project I have worked on in the last decade....Provided proper care is taken regarding object lifetime management, heap fragmentation, and a few other issues.

Even in projects such as real-time control of industrial robotics or highspeed communications [eg where keys change at rates of 1Khz or more] the heap has not beome an actual issue.

[_uj]

Not at all, at least not in any project I have worked on in the last decade....Provided proper care is taken regarding object lifetime management, heap fragmentation, and a few other issues.

Are you able to raise beyond yourself and consider the general problem?

[TheCPUWizard]

Are you able to raise beyond yourself and consider the general problem?

Did YOU read the material I posted back in reply #3. It goes into complete details (many pages alongwith other references) that are simply impractical to cover in a simple forum post.

In summary.

1) Be careful about object lifetime. Are you calling new/delete at the most efficient times? Can you "re-use" blocks instead of returning them to the general heap?

2) Be careful about heap fragmentation. Are you alloction sizes consistant? If you are allocating many differing size blocks it (potentially) complicates the heap structures.

3) Measure the amount of time (and locations in the program) where you are doing the new/delete.. One of the simplest ways to do this is to override the globl new/delete (I use a technique similar to what VC++ does for "_DEBUG" configurations). Can you changing the timing to be more efficient?