[llvm-commits] Fwd: Patch for review: Speeding up ScheduleDAG computations

Chris Lattner clattner at apple.com
Thu Mar 6 21:23:54 PST 2008


On Mar 6, 2008, at 12:17 PM, David Greene wrote:

> On Wednesday 05 March 2008 21:52, Chris Lattner wrote:
>
>>>> Right, it's very malloc intensive. That's the main issue.
>>>
>>> So why not define an allocator for it?
>>
>> See the previous response.
>
> Couldn't an allocator also handle fragmentation and layout?
>
> I agree that the standard containers aren't always optimal but I  
> think it's
> a mistake to dismiss them out of hand.  Most of the time we just don't
> care because they're not in performance-critical parts of the code
> (understanding that this case IS a performance-critical piece of  
> code).

Common implementations of std::set<void*> have 3 words of overhead per  
pointer stored (300% overhead!) not counting overhead from the malloc  
implementation (probably another word, aka another 100%).

std::set is not a good data structure for small elements.  For large  
elements it can be very nice.  This is discussed here: http://llvm.org/docs/ProgrammersManual.html#ds_set

-Chris



More information about the llvm-commits mailing list