<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 16, 2008, at 8:20 AM, Roman Levenstein wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br>So, we can see, that performance-wise the difference is not that huge.<br>But if we look at the number of new/delete calls, then it is quite different:<br>1) without STL standard allocator - Total of only 847(!!!) mallocs for<br>all of the allocators together, while adding 1000000 nodes for each<br>of them.<br>2) with STL standard allocator - Total of 2000628 mallocs for all of<br>the allocators together, while adding 1000000 nodes for each of them.<br><br>So, the standard allocator of STL produces a huge number of<br>new/delete calls. And other allocators reduce it<br>by almost 4 orders of magnitude. But, as mentioned before, it DOES NOT<br>result in a big performance difference on<br>my Ubuntu/Linux/x86 machine, which indicates that mallocs are very<br>efficient here. But for you it seems to be very different...<br></span></blockquote></div><br><div>Hey Roman, it would be interesting to measure the locality effect of using new/delete. Also, I don't know how your setup is arranged. In the case of LLVM, the heap is significantly fragmented before a pass starts beating on (f.e.) a std::map. When the nodes go through malloc, this means that the nodes for one map end up scattered throughout the heap. My guess is that this makes traversals far more expensive than when using a pool allocator that makes them contiguous.</div><div><br class="webkit-block-placeholder"></div><div>Relevant reading :)</div><div><span class="Apple-style-span" style="font-family: 'Lucida Grande'; font-size: 11px; "><a href="http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html">http://llvm.org/pubs/2005-05-21-PLDI-PoolAlloc.html</a></span></div><div><br class="webkit-block-placeholder"></div><div>-Chris</div></body></html>