Heap efficiency?

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?

Quote:

---

Originally Posted by _uj

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

---

This all depends on the compiler and implementation.

Regards,

Paul McKenzie

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.

Quote:

---

Originally Posted by Paul McKenzie

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.

Quote:

---

Originally Posted by _uj

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.

Quote:

---

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

Quote:

---

Originally Posted by TheCPUWizard

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

---

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

Quote:

---

Originally Posted by Paul McKenzie

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)?

Quote:

---

Originally Posted by _uj

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.

Quote:

---

Originally Posted by _uj

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.

Quote:

---

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

Quote:

---

Originally Posted by Lindley

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?

Quote:

---

Originally Posted by _uj

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

---

:eek:

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 :eek: (the more advanced programmer may simply need a large bottle of extra strength headache medicine.

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?

Quote:

---

Originally Posted by _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?

---

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.

Quote:

---

Originally Posted by TheCPUWizard

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?

Quote:

---

Originally Posted by _uj

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?

Quote:

---

Originally Posted by TheCPUWizard

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?

---

Is this advocating liberal use of placement new or an allocator that does all this for you behind the scenes such as the small object allocator in Loki?

Quote:

---

Originally Posted by Russco

Is this advocating liberal use of placement new or an allocator that does all this for you behind the scenes such as the small object allocator in Loki?

---

Actually it is advocating...

1) READ the material from the book mentioned in Reply #3

2) Run experiments with YOUR compiler on YOUR (target) hardware, and measure the performance differentials for various alternatives.

3) Measure your application performance against a defined performance specification.

4) IF Your application measurements show insufficient performance, AND if the amount of time measured for heap management is significant AND IF the differential experiements performed earlier indicate that any one of the three items (mentionedin previous posts), then those methodologies should be applied.

In general I recommend against "liberal use" of anything "throughout" an application. IT is (in general) easier to implement, test, measure, and maintain something (such as placement new, or a small object allocatior) if it is encapuslated and centrally implemented.

I've investigated this matter further and come to a conclusion.

The reason I became worried about heap efficiency in the first place was a line from Modern C++ Design by Andrei Alexandrescu. It reads: "For occult reasons, the default allocator is notoriously slow". He then goes on to address the problem by designing a small object allocator to serve as a replacement.

I interpret this to mean that it's the consenus view of the C++ community that the default allocator supplied with common compilers generally is too slow to handle a programming style which makes frequent use of object allocations on the heap, such as for example OO (object oriented) programming. I also interpret this to mean that it's a very good idea to replace the default allocator with something more efficient.

What I didn't realize at the time was that I already had what I was looking for. I'm using TBB, an open source fine-grain multithreading library from Intel. I post a link here to an article describing the TBB memory allocator for two reasons. Firstly it's independent from the rest of the TBB package so people may want to consider using it although they may not be interested in multithreading for the time being. And secondly the article contains references to other allocators, both free and commersial.

ftp://download.intel.com/technology/...e_Software.pdf

My conclusion is that for serious OO programming to be feasible in C++ the standard memory allocator must be replaced with something more efficient. The standard allocator sucks and is likely to be a major bottleneck. That's the plain and simple truth, and it amazes me that this fact isn't out more in the open, especially since C++ is considered to be THE language for efficiency conscious programmers. I suggest anybody with an ambition to write fast and nimble OO programs immediately starts looking for a better memory allocator.

Quote:

---

Originally Posted by _uj

My conclusion is that for serious OO programming to be feasible in C++ the standard memory allocator must be replaced with something more efficient. The standard allocator sucks and is likely to be a major bottleneck. That's the plain and simple truth, and it amazes me that this fact isn't out more in the open. Especially since C++ is considered to be THE language for efficiency conscious programmers. I suggest anybody with an ambition to write fast and nimble OO programs immediately start looking for a better memory allocator.

---

In order to support that conculsion, you would have to analyze a sample set of applications with different allocators, and measure the application level performance difference.

But there is an even eaiser way to contratict your conclusion...There are hundreds of thousands of C"Serious OO programs" written in C++ using the default allocator. If you conclusion were true, then these programs would not exist.

I HAVE done a significant amount of performance analysis on applications ranging from massive business applications to high performance real-time systems (including industrial process/machine control and military weapons systems [no good shooting where the plane was]. Only in very very rare cases was heap management even measurable as an impact on performance.

The following numbers are from a project I just completed on real-time gas dispersion:

Sample Time: 132.3 mS
Heap Allocations: 32,418
Heap ManagemenrtTime: 2.83mS

So we have (using the allocator provided with VC++ 9.0, a 2.13% time spent dealing with the heap.

Assume you have an allocator which is 100 times faster. You would get.

Sample Time: 129.5 mS
Heap Allocations: 32,,418
Heap Management Time: 0.0283mS

This represents a 2.11% performance improvement. Hardly a significant issue.

You are falling into the trap of premature optimization. The cases where an optimized allocator makes sense is when the number of (small) allocation/release cycles are extremely high AND there is little or no code in the constructor/destructor [ie you are making heavy use of the FlyWieght pattern]

---

Quote:

---

Originally Posted by TheCPUWizard

Only in very very rare cases was heap management even measurable as an impact on performance.

---

Contrary to your personal experience C/C++ applications allocate quite a lot of dynamic memory. In the Intel link I supplied there's a reference to a study which shows that rather 20% of the execution time is spent allocating memory than 2% (as your example suggests). This study is from 1994 and with the increasing use of OO the percentage is more likely to be higher today than lower.

Quote:

---

You are falling into the trap of premature optimization.

---

Well, in that case I'm in good company. I'm sure Alexandrescu didn't design a small object allocator in his book just to show off, but because he felt there's a need for one.

Introducing a more efficient memory allocator will in fact counteract premature optimizations. The reason is that if programmers feel object allocations are expensive they will avoid them and this will negatively influence the proper use of OO. Proper object allocations will be avoided for the sake of reducing heap usage, and that's premature optimization. In principle inefficient object allocation is the worst enemy of good OO design.

What says exactly the standard memory allocator has the ultimate level of efficiency? If a compiler supplier improves the standard allocator are they then guilty of premature optimization? If not, why is improving the standard allocator a virtue but replacing it a sin?

So my conclusion still is that if you're into modern OO, which relies on generous object allocation (including shared smart pointers), it's a very good idea to replace the standard memory allocator, just like Alexandrescu suggests. And if you program to utilize multiple processor cores, then using a more efficient object allocator is close to mandatory.

I feel I have heavy support for my view. I specifically draw on the Modern C++ Design book by Alexandrescu, a book you yourself in this thread recommended every programmer to read and understand. I also draw on the experience of Intel designing the TBB library.

Hi _uj, thanks for the interesting paper...

Quote:

---

Originally Posted by _uj

In the Intel link I supplied there's a reference to a study which shows that rather 20% of the execution time ...

---

I was so shocked to see this result that I felt the need to read it;

Actually both the Intel paper and the referenced paper do not speak of a <mean> relative execution time of 20%:
the intel paper speaks of un upper estimate and the Detlefs's paper reports such high ratios only for 2 over 5 allocators (one of which implements a garbage collector).
Furthermore, all mentioned non-garbage collected allocators exhibit a high variance of results (GNU: mean<17%>,min<1.6%>,max<52%>, ULTRIX: mean<6.97>,min<0.6%>,max<20%>, ...) indicating a high specificity on algorithm allocation usage.

Moreover, relative instruction counts were measured reather then relative execution times: the two concepts coincide only neglecting idle time (that is wrong, in general)

( It's also curious that the most allocation dependent code reported in that paper is CFRAC: a large integers factoring program ! ... )

Of course, the problem of memory allocation in a multithreaded environment has an entirely different perspective:

by the way, I have a question for you: as the Intel paper argues, heap access needs some synchronization mechanism; fixed a "typical" C++ compiler + standard allocator + OS, what's the relation between heap locking and object costruction ? (for example, does the heap remain locked until object costruction is fully completed (eg until the ctor returns) ? )

As you pointed out, the Intel study was done 15 years ago (published 14 years ago). Much has changed since then. As object complexity increases (especially constructor complexity with the adoption of RAII) the dynamics radically change.

Consider the following code:

Code:

---

Code:
{
  MyClass  instance1;
}

{
  MyClass *instance2 = new MyClass();
  delete instance2;
}The overhead of the heap management is the DIFFERENCE in the times.

---

When the intel study was done, it was based on "C" code which did NOT have constructor/destructor semantics. The initialization of state for the instance was done OUTSIDE the timed regions.

This radically skewed the impact when applied to complex C++ objects.

For most applications, performance tuning comes NOT from changing the allocator, but rather from the usage of Object Pools. It is typically much faster to restore an object instance to a known state then it is to initialize an object from scratch.

The result is that the percentage of time in allocation/deallocation dramatically to 2%-5% of the total time.

Quote:

---

I specifically draw on the Modern C++ Design book by Alexandrescu, a book you yourself in this thread recommended every programmer to read and understand

---

Definately!...Now look at the last word that I quoted.

The default allocator is designed to give "reasonable" performance under "worst case" conditions. This means that it will "work" for nearly every application. The cost of this is a sacrifice in performance under specific conditions (most notably large numbers of small allocation/release cycles).

Nearly every replacement (including Alexandrescu's and Intel's) will have worse performance than the default allocator under specific conditions. In some cases (especially varying size large allocations on low memory systems) it will be much worse.

This is where understanding becomes critically important, and this understanding comes from actual measurements [of application level performance, NOT micro-benchmarking) performed on real applications using real data on actual systems.

There ARE cases where avoiding the default allocator is a relatively obvious choice. It can be avoided either by using a diefferent allocator, or by implementing a pool explicitly (both accomplish the same thing of having a ready supply of memory blocks of a specific size).

A good case in point is an image processing application where individual pixels are going to be represented by distinct objects using the Flyweight design pattern. In this case you may have 100 million (or more) allocations (each of size_t *n n=1,2,3). Even uS differences in allocation speeds will translate to minutes of processing time. [The PET scan processor I helped develop took this approach with 1GB+ raw data samples).

Even in this extreme case, it made sense [based on timing analysis] to implement a custom scheme ONLY for the flyweights, and let all of the other objects use the default allocator.

Well I agree more with that last analysis. For specific cases it may make sense to have a specific allocator for those kinds of objects. I've had plenty of examples where I used a custom allocator because something around 50&#37; or more of the time was spent on heap management. However I've only used those on the objects that were posing the problem. Undo management, parsing trees and string caches are the examples that come to mind. However the advice is mostly as everyone has already said:
Measure how much it represents and if it's important then find a way to change it.

A general OO program that doesn't crunch data and has to maintain huge collections with non-standard execution behavior doesn't suffer from the standard allocators. They are actually designed so they can handle those cases well.

i dont understand how a reallocation improved allocator, talking about malloc or heapalloc and the heap expansion function, with placement new[] can be any worse in any scenario. I dont buy it. Give me the example!

Ofcourse placement new only has to be called on non-POD classes, this can even improve performance by ALOT. and this is easily done by using a typeinfo class.

i dont know anything about STL, so i have no idea if an allocator can implement the typeinfo class in that way.

also since when is it standard to expect "low memory" systems?
and since when do all systems have swapfiles?

Quote:

---

Originally Posted by cj-wijtmans

i dont understand how a reallocation improved allocator, talking about malloc or heapalloc and the heap expansion function, with placement new[] can be any worse in any scenario. I dont buy it. Give me the example!

---

THREE typical examples...

1) On the very first allocation, the allocator must get memory from the system. Generally this can not be done faster than the default allocator does it. There is almost always additional overhead to set up the tracking structures that the "optimized" allocator will use.

2) Many implementations use the following (psuedo code) pattern:

Code:

---

void *MyAllocator(int size)
{
  if (size < threshold)
      return GetOptimizedSmallBlock();
  else
      return SystemAllocatedMemoryBlock();
}

---

By the very definition, this implementation will NOT be faster than a first call to "SystemAllocatedMemoryBlock".

3) [previously mentioned, but repeated for completeness]. The application requests large blocks (relative to the amount to total heap available) in varying sizes (non-repeatable) with overlapping allocations. Any scheme which retains blocks of a given size for faster access will NOT find appropriate memory blocks. It must then fall back into a searching pattern. Because of the focused optimization for repeated allocations of the same (typically small) size, it is common that this path incurs additional overhead (e.g. checking the initial lists of known block sizes)

I am willing to state, that if you give me ANY implementation, I can find at least one case where the timing is worse than the default allocator.

Hi TheCPUWizard, your examples are very convincing but you defined "heap overhead" as

Code:

---

{
  MyClass  instance1;
}
/* <-- DIFFERENCE in the times of --> */
{
  MyClass *instance2 = new MyClass();
  delete instance2;
}

---

but _uj's concern was about the impact of heap synchronization in multithreaded environments, where such a time difference isn't,in general, well defined.

Maybe I'm missing something obvious, but how can you state that the default allocator (that I suppose makes sequential accesses to a shared heap) is optimal in heavy multithreaded C++ appications ?

Quote:

---

Originally Posted by superbonzo

Maybe I'm missing something obvious, but how can you state that the default allocator (that I suppose makes sequential accesses to a shared heap) is optimal in heavy multithreaded C++ appications ?

---

Actually I never did.

My statement is and always has been that:

Quote:

---

The default allocator, has been designed to give decent performance across the widest range of applications, while replacement allocators are targeted towards specific situations. Therefore until you have mesaured a specific situation, you do not know the impact of the allocator, and stating that it must be changed, is a premature decision.

---

The conslusion that can be drawn from this statement is two fold:

1) For ANY specificcondition, and allocator can be designed that will perform better than the default allocator.

2) Until you know the specific characteristics, you do not have suffient information to know if the allocator is a significant impact to application level performance. Nor do you know which replacement allocator will be best.

Much has focused on "small objects", but the situation with heavy multi-threaded applications is very similar. In the past 18 months I did two heavily threaded applications (100+ active threads running on SMP servers).

The first used a messaging system to communicate between threads. The threads did alot of dynamic data processing. The only cross thread data was the messages (and related synchronization). The chosen design was that each thread got its own heap, and memory (other than the messages) had to be allocated and freed on the same thread. NOTE: this is very similar to the way memory across DLL's can be handled.

The second did intense CPU processing on the threads along with some IO. Data was heavily shared, but 90&#37;+ of the allocations occured on one specific thread. The percentage of time spend being blocked (due to serialization of the heap management) was negligable, and no specific action was taken.

Again, at no point did I ever saw that custom allocators were "bad", or any such thing. Simply that until you analyze a specific application and determine that the allocator is a significant issue, there are many many more important issues to be concerned with.

Remember the original question was: (emphasis added)

Quote:

---

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

---

And I stand by my statement, that when looking at typical applications that are well designed, it is generally efficient enough to NOT be a primary or even secondary concern.

Quote:

---

Originally Posted by TheCPUWizard

And I stand by my statement, that when looking at typical applications that are well designed, it is generally efficient enough to NOT be a primary or even secondary concern.

---

And I still think my conclusion is correct. In a typical well designed OO application (characterized by generous object allocations on the heap and ubiquitous use of non-intrusive smart pointers) the standard memory allocator will be a major bottleneck. I think there's a very good reason why Alexandrescu devotes 20 percent of his much acclaimed Modern C++ Design book to efficient small object allocation and smart pointers.

I used to avoid heap allocations for performance reasons even though I knew I shouldn't for design reasons. I'm sure many share this experience with me. Knowing I have an efficient heap allocator has put an end to this self-destructive behaviour. This psychological effect shouldn't be underestimated. So in addition to having a real effect on runtime performance, efficient object allocation also helps avoid premature optimization.

I realize my conclussions are based on hearsay and personal experience. Therefore I would wellcome an ambitious investigation from some independent party into how different allocators influence the performance of OO programs. If it turns out that standard (or maybe they should be called general) allocators are good enougth then fair enougth. But until then I prefer an allocator with the outspoken objective of performing well under the OO programming style. That's the "standard" allocator I want. I don't quite understand why there's such an opposition to such a wish. Why would it be so much better if I use the allocator that came with the compiler?

Anyway I've made up my mind so I leave this discussion. Thank you all for your input.

Quote:

---

Originally Posted by _uj

. I think there's a very good reason why Alexandrescu devotes 20 percent of his much acclaimed Modern C++ Design book to efficient small object allocation and smart pointers.

---

One has nothing to do with the other. And 18 out of 314 pages is less than 6%. This means that 94% of the book has NOTHING to do will allocatrion. Even that 6% is related specifically to small object allocation, and not allocation in general. Even with in that chapeter the performance is referred to as a "bump in the road" (pg 78) and not as a major issue in the persuit of an efficient C++ program..

Quote:

---

I realize my conclussions are based on hearsay and personal experience. Therefore I would wellcome an ambitious investigation from some independent party into how different allocators influence the performance of OO programs. If it turns out that standard (or maybe they should be called general) allocators are good enougth then fair enougth. But until then I prefer an allocator with the outspoken objective of performing well under the OO programming style. That's the "standard" allocator I want. I don't quite understand why there's such an opposition to such a wish. Why would it be so much better if I use the allocator that came with the compiler?

---

Because (Alexandrescu , Sutter, and Meyers agree) the relevance of this issue is specific to the type of application, the comparision has to be done for specific application.

YOU alread have a set of applications where you have used an alternate allocation.

You should have performance metrics (time and resources) of each application level action. For a GUI application (desktop or Web) this means response times for each possible user action (button click, menu selection, etc.) under a variety of conditions. [A typicall application will have anywhere from a few dozen sample points to a few hundred, and large applications may have a few thousand]. These should all be part of you normal testing process and proceedures.

Take your existing applications and simply disable the replacement allocator (should be commenting out just a few lines) , and re-run the same suite of tests. Compare the numbers as a percentage, relative to the specification for each item.

You will then have a documented case of how many places in your application your replacement allocator allowed you to meet a specification where the default allocator would have caused a failure.

And most importantly, the number will be based on your specific style of writing applications, and therefore likely be applicable to future works.

Quote:

---

Originally Posted by TheCPUWizard

One has nothing to do with the other. And 18 out of 314 pages is less than 6%. This means that 94% of the book has NOTHING to do will allocatrion. Even that 6% is related specifically to small object allocation, and not allocation in general. Even with in that chapeter the performance is referred to as a "bump in the road" (pg 78) and not as a major issue in the persuit of an efficient C++ program..

---

I referred to small object allocation AND smart pointers. These two topics constitute approximately 20% of the book.

Although policy-based design may be the main message of the book it also carefully describes the design and implementation of an actual library called Loki. In my view the fact that 20% of the book is devoted to efficient small object management is a very strong indicator of the importance of these topics in modern C++ design.

And this is what Alexandrescu actually says about it (in 4.10 Summary):

---

"Some C++ idioms make heavy use of small object allocation on the free store. This is because in C++, runtime polymorphism goes hand in hand with dynamic allocation and pointer/reference semantics. <snip> This renders the default free store allocator unsuitable for allocating small objects because it is often slow and brings nonnegligible per-object memory overhead. <my emphasis>

The solution is to rely on small-object allocators - specialized allocators that are tuned for dealing with small memory blocks (ten to hundreds of bytes)"

---

To me it couldn't be clearer. If you're into the OO programming style and make heavy use of small objects (like smart pointers for example) then it's a very good idea to use a better allocator than the "standard". Nothing will convince me that this isn't what he says.

Quote:

---

Originally Posted by _uj

To me it couldn't be clearer. If you're into the OO programming style and make heavy use of small objects (like smart pointers for example) then it's a very good idea to use a better allocator than the "standard". Nothing will convince me that this isn't what he says. So I stop here.

---

WHEN do you ever allocate SmartPointers as standalone objects on the Heap???? Smart pointers are 90%+ of the time...

1) Created on the stack.
2) Members of a larger allocation (ie the containing object).

If you have code that looks like:

Code:

---

smart_ptr *p = new smart_ptr();
//... use pointer
delete p;

---

Then you have a very unusual programming style.

Please post a histogram of the allocations from one of your programs (x-axis =size; y-axis=count).

You are also ignoring the fact that (nearly) every reference you have provided uses terms such as "often","typical","common". Without a context, these are totally subjective. As an example 0.001% (1 in 10,000) is the definition of a "common side-effect" in pharmacuticals, and 1ppm (1 in 1,000,000) is the standard measure for a "typical presence" when measuring purity of bi-layered optics. I personally consider a software situation "often" if I encounter it 2-3 times over a 5 year period dealing with my clients.

Lastly, smart pointers, NEVER provide a performance improvement (in either size or time) over raw pointers. At best they impose a negligable performance penalty. Their purpose is to improve reliability and maintainability. As such they have no bearing on this discussion; yet (based on the length of material) Andre considered them more than twice as important.

Quote:

---

Originally Posted by TheCPUWizard

WHEN do you ever allocate SmartPointers as standalone objects on the Heap????

---

I'm talking about non-intrusive reference-counting smart pointers, like the one in Boost that's suggested for the upcoming C++ standard. This kind of smart pointer is almost always implemented with the reference counter (typically a long) allocated on the heap.

This is why intrusive smart pointers may be of interest for performance reasons. Here the reference counter is made part of the class so when an object is allocated on the heap the counter is already part of it. This avoids an extra heap allocation for just the counter of the smart pointer managing that object.

Quote:

---

Then you have a very unusual programming style.

---

No, my programming style is normal. It's just that I know how smart pointers work under the hood. This is also why I know to appreciate a small object allocator.

There is a nasty implication in your last post, that I do not "know how smart pointers work under the hood". I am sure that would suprise the multiple vendors who utilize my firm and I for their pre-beta review and testing.

I am just going to wait for you to post (publically or privately) the comparitive performance and/or the distribution histograms that will provide evidence of your point of view.

For other readers who are following this thread (based on the relatively high read count..)

Lets look at Boost and the implementation of shared_ptr.

Quote:

---

“Boost is one of the most highly regarded and expertly designed C++ library projects in the world.”

— Herb Sutter and Andrei Alexandrescu, C++ Coding Standards

---

This is a non-intrusive reference counting pointer (meaning the reference count is managed by the pointer system and not by the object itself).

The key declaration is:

Code:

---

class sp_counted_base
{
private:
    long use_count_;        // #shared
    long weak_count_;      // #weak + (#shared != 0)

public:
    virtual ~sp_counted_base() // nothrow
 //...
}

---

This means that the object size is going to be:

Code:

---

sizeof(sp_counted_base) = 2*sizeof(long) + sizeof(vptr).

---

Which means a fixed size on most (32 bit) machines of 24 bytes - the exact size is not important, the main points are:

1) ALL Instances are the same size
2) Instances do NOT reference other blocks of memory
3) The instance size IS (what nearly everyone would consider) SMALL
4) The instance size IS NOT the sizeof(T *) nor of sizeof(smart_ptr<T>).
5) There are likely to be a large number of thiese instances created and destroyed during application execution.

When combined these traits directly match the conditions where the standard allocator's performance is at its worst.

Yet the boost library DOES NOT REPLACE THE DEFAULT ALLOCATOR! because of this.

Rather it follows the approach of specifically (with various options based on preprocessor definitions of BOOST_SP_USE_STD_ALLOCATOR and BOOST_SP_USE_QUICK_ALLOCATOR) of overriding operator new for the specific class in question. (sp_counted_impl.hpp in the details subdirectory).

Quote:

---

Originally Posted by TheCPUWizard

There is a nasty implication in your last post, that I do not "know how smart pointers work under the hood". I am sure that would suprise the multiple vendors who utilize my firm and I for their pre-beta review and testing.

I am just going to wait for you to post (publically or privately) the comparitive performance and/or the distribution histograms that will provide evidence of your point of view.

---

Well, pulling rank won't strengthen your argumentation. It's pretty obvious from post #34 that you're not aware of the fact that shared smart pointers allocate a reference counter on the heap (and that they therefore benefit significantly from a small object allocator).

I'm not into the "look at me" argumentation you seem to favour. You'll have to make do with public evidence. This for example are timings of different implementations of the the Boost Shared Pointer,

http://www.boost.org/doc/libs/1_37_0...smarttests.htm

Loser is "simple counted" which uses heap allocation. Winner is the intrusive pointer, but almost as good is "special counted" which uses the equivalence of a small object allocator.

Guys I don't think all this is necessary.

Keep in mind whining will show up for years, unless the thread is reworked, and all this complaining is searchable from google.

How embarrasing for the two of you right?

Quote:

---

Originally Posted by _uj

I'm not into the "look at me" argumentation you seem to favour. You'll have to make do with public evidence. This for example are timings of different implementations of the the Boost Shared Pointer.

---

What more public evidence do you wwant than my last post, were I showed (and the link you posted to the timing is based on), that the
DEFAULT ALLOCATOR for the application is not changed.

Specifing the use of a applicator based upon the characteristic of a class is something I am fully in support of, and do many times. It is your position (as I understand it), that replacing the DEFAULT ALLOCATOR on a global basis is a "good thing".

Quote:

---

Originally Posted by TheCPUWizard

It is your position (as I understand it), that replacing the DEFAULT ALLOCATOR on a global basis is a "good thing".

---

Replacing the default allocator is neither good nor bad. The default allocator is just the allocator that came with the compiler. If I can find an allocator that is better suited to my programming style (OO) I rather use that as my "default". I have come to the conclussion that an allocator specialized in handling small object efficiently suits me better.

Why do you have this desperate need to stick with exactly the allocator that came with the compiler? Does the thought of replacing it give you separation angst? Or does it maybe have unknown divine properties you want to tell us about?

Quote:

---

Originally Posted by _uj

Replacing the default allocator is neither good nor bad. The default allocator is just the allocator that came with the compiler. If I can find an allocator that is better suited to my programming style (OO) I rather use that as my default. I have come to the conclussion that an allocator specialized in handling small object efficiently suits me better.

---

But (Again to the best of my understanding), have done ZERO quantitaive measurements to support this. IF I believe that variables should never have the letter O in them, with absolutely no quantitative evidence to support this position. I dont see a difference.

Quote:

---

Why do you have this desperate need to stick with exactly the allocator that came with the compiler? Does the thought of replacing it give you separation angst? Does it have divine properties you want to tell us about?

---

Very very simple. As soon as you replace the default allocator, you take on the full responsibility of testing EVERY piece of code that uses that allocator. This means testing the vendors runtime, support libraries (including STL implementation), application frameworks, everything. Considering that these items usually require a least few man-years to test comprehensively, this would price almost every application out of existance. Or do you believe in shippijng untested code?????

I will always choose a supported environment over a custom one, provided it can be used to meet the design specifications. From a professional point of view, it is more expediant to use something (that may take twice as much memory, and ten times as long to run) which has the full faith and support of a vendor than to over-"optimize" when that has no bearing on the application meeting the clients specifications.

I would not call these properties "divine", but they have served me very well, for a very long time.
===

One of the worst experience I had (over 25 years ago) was an application that used a custom B-Tree (this was long before commercial data management systems were available for PC type applications).

Occasionally (2-3 times per year with an installed client base of over 100 systems), the entire database would trash itself. More and more tests were written to test the library, but none of them found a problem, no matter how hard we tried.

Eventually one of us (ironically a high-school intern) found that with a certain combination of key length's and physical record numbers, an internal buffer was 1 byte too short.

A similar thing is possible [although hopefully very unlikely] when one alters the environment to vendor provided library. If I known that everything has been tested using the compiler supplied allocator, have no reason to believe they would have tested it with another allocator, and the performance is acceptable, where is the value in the increased risk?

Quote:

---

Originally Posted by _uj

Why do you have this desperate need to stick with exactly the allocator that came with the compiler? Does the thought of replacing it give you separation angst? Or does it maybe have unknown divine properties you want to tell us about?

---

Bravo!.....:sick: Excellent Whining!
Clap clap clap!

Quote:

---

Originally Posted by ahoodin

Bravo!.....:sick: Excellent Whining!
Clap clap clap!

---

That's not whining, that's plain-talk. It's a way to get to the gist of an argument and get it noticed. But thank you for your kind review of my posting style.

Quote:

---

Originally Posted by ahoodin

Bravo!.....:sick: Excellent Spamming!
Clap clap clap! *im a retard, weeeee*

---

yeah...

The point is that it is possible to make your point in a matter of fact way without all the theatrics. Especially without all the useless insinuations and pointless nasty whinings.
Also please put some pants on if you are going to post here!;)

:D:D:D

Quote:

---

Originally Posted by TheCPUWizard

But (Again to the best of my understanding), have done ZERO quantitaive measurements to support this. IF I believe that variables should never have the letter O in them, with absolutely no quantitative evidence to support this position. I dont see a difference.

---

As I've told you several times, I don't use "look at me" argumentation. I just don't think personal results are valid evidence. Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation. Maybe you should do the same.

Quote:

---

Very very simple. As soon as you replace the default allocator, you take on the full responsibility of testing EVERY piece of code that uses that allocator.

---

Not necessarily so if the provider of the default allocator and the replacement allocator is the same. As you may know Intel offers a popular C++ compiler. Intel also offers a replacement allocator as part of its TBB library. I'm sure Intel takes as much responsibility for the TBB allocator as it does for the standard allocator it ships with the compiler.

Having said that I realize that the most common situation may be that the replacement allocator doesn't come from the compiler provider. In that case there may be the implications you suggest but only if I've developed the allocator myself. Otherwise - no.

You have somehow arrived at the conclussion that original parts must always be better than third-party parts. This is a dire proposition for two reasons. Firstly it just isn't true. Third-party parts are likely to have been developed to the same high standard as the originals, if not even higher for the simple reason that otherwise they wouldn't sell. And secondly, it may give you a false sense of security. When an original part you unconditionally trust does fail you may be standing with your pants down because you didn't plan for what you thought could never happen.

So the secure world you've built yourself with original parts is nothing but an illusion. Cozy to be in but potentially dangerous if it makes you exclude the unexpected from your product testing.

Quote:

---

Originally Posted by _uj

As I've told you several times, I don't use "look at me" argumentation. I just don't think personal results are valid evidence. Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation. Maybe you should do the same..

---

I did, but you seem content to ignore Reply #37.

Quote:

---

Instead I stick with qualitative arguments and peer reviewed results. And of that I've posted plenty in support of my argumentation.

---

Your argument is a classic non sequitur.

Your source says one thing ("it is sometimes beneficial to use a custom allocator"), but you interpret something completely different from it ("for serious OO programming to be feasible in C++ the standard memory allocator must be replaced with something more efficient. The standard allocator sucks and is likely to be a major bottleneck") and then argue as if your interpretation is fact.

Quote:

---

Originally Posted by TheCPUWizard

I did, but you seem content to ignore Reply #37.

---

I didn't ignore it, I wrote it. :)

And look who's talking. How come you dodged the seconds part of my post #46? Yes that's right. That's where I rip apart your pet argument about not replacing the standard allocator.

Oh will the real slim shady please stand up?:thumbd:

This thread is garbage!