Heap efficiency?

[TheCPUWizard]

Yes, but how does that conflict with what I stated? My understanding is that placement new is used in the standard allocator's construct member function.

Internally, it may be... creating an object involves two steps:

1) "Selecting" (for lack of a better word) a memory address or contigous block for items with sizeof()>1. This can be on the stack, dynamically aquired from the allocator (by default on the general heap), or specified by the caller.

2) Invoking the constructor, passing the effective base of this memory as the this pointer.

Of the three:
1) Memory on the stack
2) Memory allocated at the time of the call
3) Memory with the address specified.

Only the second one is relevant to any discussion about performance (how long it takes and how much memory is consumed). Condition #1 is a fixed compile time offset from the stack pointer, and Condition #3 is a parameter passed to a routine.

In psuedo code, this may be:

*Object New()
{
     *Memory = AllocateMemory();
     *Object = InvokeConstructor(*Memory);
}

*Object PlacementNew(*Memory )
{
     *Object = InvokeConstructor(*Memory);
}

Or may be:

*Object New()
{
     *Memory = AllocateMemory();
     *Object = PlacementNew(*Memory);
}

*Object PlacementNew(*Memory )
{
     *Object = InvokeConstructor(*Memory);
}

The latter is likely to be a common implementation. But the impact of replacing the allocator (either on a per-class basis, or globally) is to replace the psuedo-"AllocateMemory()" functionallity.

[ahoodin]

This part is clever?

I drive a hard bargain and if the proverbial emperor has no clothes on he can rest assure I'm going to point it out.

hmmm

I know I sometimes overdo it but then I'm willing to rephrase, which I've done in this thread.

You are a confused individual. Quite trying to rationalize your nastiness. There is no excuse.

I make no special provisions for rank or seniority or previous accomplishments.

So you have no respect.

Nobody is better than their last argument. I try to produce good and sharp arguments in a style that's interesting and to the point, even provokative.

Now I know your full of it. People miscommunicate all the time, and they should be given an opportunity to explain without sharp verbal barbs.

I know I sometimes overdo it but then I'm willing to rephrase, which I've done in this thread.

If you want this thread in that CG book - keep out!

I guess your experiences didn't teach you manners.

I know I sometimes overdo it but then I'm willing to rephrase, which I've done in this thread.

[Hermit]

.

I feel I need to point out that while you criticize _uj for his acerbic posting style, saying that it detracts from the informational content of the thread, you yourself have contributed nothing regarding the topic of interest. Of course, if I stopped there, my head might explode pondering what vice it would be to accuse you of hypocrisy yet do the same.

On to heap allocation.

TheCPUWizard is certainly correct on the point that it is senseless to use anything but the default allocator unless you are sure that it would be advantageous in a specific scenario. I do not, however, think you need to go as far as to run benchmarks in order to reasonably ascertain that high-frequency small object allocations can benefit from a special allocator (at least one from as reputable a vendor as Intel).

The real argument here apparently rises from the question of whether or not it is reasonable to write performance-conscious code even when doing so does not have a meaningful impact on the overall performance of the program (with respect to performance constraints that actually matter to users of the software, not just arbitrary benchmarks). I'll side with _uj here in saying that, even if the advantages are slim, if there are no disadvantages to a particular design decision then why not go with it? Are there really any disadvantages to using a well-tested third party allocator? I don't think the point made by TheCPUWizard regarding the risks involved was at all accurate (the example he cited regards home-brew, not reputable third party code). If there were a downside, I would say that using a non-standard library for small object allocation may incur some (probably small) cost when it comes to training new employees, and only because this probably reflects a broader company policy of using third party libraries for things normally done by standard ones.

So my overall point is that if you want to use a small-object allocator for (gasp) small object allocation, that's probably fine. Don't get the idea that OO in C++ is doomed without it though.

[cj-wijtmans]

ignoring all the ignorant poeple that are saying the default allocator is good enough.

take a look here:
http://zdavatz.wordpress.com/2007/07...-ruby-process/
http://blog.pavlov.net/2007/11/11/wi...entation-heap/

[TheCPUWizard]

TheCPUWizard is certainly correct on the point that it is senseless to use anything but the default allocator unless you are sure that it would be advantageous in a specific scenario. I do not, however, think you need to go as far as to run benchmarks in order to reasonably ascertain that high-frequency small object allocations can benefit from a special allocator (at least one from as reputable a vendor as Intel).

The real argument here apparently rises from the question of whether or not it is reasonable to write performance-conscious code even when doing so does not have a meaningful impact on the overall performance of the program (with respect to performance constraints that actually matter to users of the software, not just arbitrary benchmarks). I'll side with _uj here in saying that, even if the advantages are slim, if there are no disadvantages to a particular design decision then why not go with it? Are there really any disadvantages to using a well-tested third party allocator? I don't think the point made by TheCPUWizard regarding the risks involved was at all accurate (the example he cited regards home-brew, not reputable third party code). If there were a downside, I would say that using a non-standard library for small object allocation may incur some (probably small) cost when it comes to training new employees, and only because this probably reflects a broader company policy of using third party libraries for things normally done by standard ones.

So my overall point is that if you want to use a small-object allocator for (gasp) small object allocation, that's probably fine. Don't get the idea that OO in C++ is doomed without it though.

Hermit,

Thanks for the comments. From a qualitative standpoint I basically agree, but the lack of a quantitative basis concerns me.

1) "If there are no disadvantages". I have yet do come across ANY designs or implementations that meet this criteria, in any domain. There is invariably some set of trade-offs in any decision process.

2)"performance-conscious code even when doing so does not have a meaningful impact". Taken to extremes, is it worth spending an extra day of development to save 1mS off of a 10 second operation? How about spending 10 minutes to cut a 10 second routine down to under 1 second? For these the answer is (almost) obvious. But the "grey area" inbetween is much more substantial. My conclusion has been that the only reliable and effective methodology is to establish performance specifications and monitor performance against these specifications. This has been validated by the majority of client firms who have adopted this process.

3)"some (probably small) cost when it comes to training new employees" My experience has been that the cost of training can be well over $20K to train a team in the use of a new library (that represents less than one week for a team of 10) - so the very definition of small can mean wildly different things for different environments. What even this figure does not include is the time, or the risk of mistakes which may result in an additional QA cycle or even a bug in the final product.

4)"a well-tested third party allocator?"The allocator may be well tested. But my concerns are with replacing the DEFAULT allocator. This means it will be used with (potentially) all of the other third-party code (eg control libraries). In general there will have been NO testing of THAT codebase with the replacement allocator. The libraries may contain bugs which are not visible will the original allocator (or with different replacement allocators that the vendor might have tested).

5)"So my overall point is that if you want to use a small-object allocator for (gasp) small object allocation, that's probably fine." I have NEVER said anything against using specialized allocators for specific tasks. My earlier post walked through exactly how the Boost Library accomplishes this.

There is no doubt that my background influences my attitude and approach.

Coming from a military/space/industrial background where true real-time performance ["No good to shoot where the plane was"] and reliability (I have worked on many projects where a failure of a system would directly result in loss of life), has instilled a bedrock of making accurate measurements over the entire lifecycle.

Running a small company for a quarter of a century, has highlighted how devastating a "suprise" (defect, missed deadline, etc) can be. It has also shown how these can be magnified for the larger companies that have been my client [At the end of 2007 I was engaged on a project with a $4 million penality if the product was not delivered in working order on Jan 3rd 2008. A one day slip would have triggered the penality, as would any single bug that caused it to fail acceptance testing]

The result is that I strive to do everything within my power to minimize risks while meeting the requirements of a project. And within this context, I will maintain that replacing the default allocator without comprehensive measurements and testing, increases the risk, without providing a known overall advantage to the functionallity, reliability, or maintainability to the final application.

[_uj]

There is no doubt that my background influences my attitude and approach.

You're confusing two aspects which should be considered separately:

1. Technology comparision. The qualities of one solution in relation to other solutions.
2. Technology selection. The selection of a proper solution for a specific situation.

I have been discussing 1, namely whether a small object allocator will make code written in the OO style more efficient compared with a general allocator. The general consensus is that it will and I've seen no good arguments from you to the contrary.

Now lets discuss 2 in situations you've raised repeatedly: real-time constraints and risk avoidance.

Should one introduce a small object allocator into a real-time program? The answer is no. Not because it's a small object allocator but because you shouldn't do heap allocations at all (for the simple reason they're not predictable as are not exceptions nor dynamic_cast nor string nor the STL containers). So the real-time situation cannot be used as an argument against a small object allocator. In that situation you shouldn't use the heap at all unless you have a special real-time allocator. If you stick with the standard allocator you can only use it during program start-up.

Now say there are no real-time requirements but instead you're extremely risk averse. The question is whether it's ESPECIALLY risky to introduce a small object allocator into a project compared with any other package? The answer is no as I've argued in #46 (to which you've failed to reply). You think you're reducing risk but that's just an illusion, and a dangerous one to boot.

So in summary your argumentation is very weak also on your own turf, namely the "look at me" arguments you draw from your own experience. Your're spreading advice quite freely so I think it's appropriate that I give you some: Heap allocation in real-time programs is a capital offense. Stop doing that. Reassess your attitude towards risk. You don't reduce risk by not using (high-quality, well established) third-party packages. The code you write yourself instead is far more likely to have bugs and cause development delays.