[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