[cfe-dev] [RFC] Embedding compilation database info in object files.

[Manuel Klimek]

On Fri, Jul 19, 2013 at 11:14 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Fri, Jul 19, 2013 at 2:08 AM, David Chisnall <
> David.Chisnall at cl.cam.ac.uk> wrote:
>
>> On 19 Jul 2013, at 10:01, Chandler Carruth <chandlerc at google.com> wrote:
>>
>> > There is no need to have it be a separate process at all. Just start a
>> background thread and join it before terminating.
>>
>> Have you benchmarked the difference between clang with and without
>> pthreads linked in?  A lot of libc and STL things become more expensive
>> (including malloc(), although not by much) when pthreads are linked, even
>> if they're not used.
>
>
> Yes, I have, and on my systems none of these things are true. I don't know
> whether or why they are true for you, but I don't think it should guide the
> decision of how to architect the Clang driver.
>
> In the not too distant future we will almost certainly want to build Clang
> as a multithreaded binary (if possible to do so) so that we can take
> advantage of threads internally.
>
>  These may be dwarfed by the CPU time of the compilation, but it isn't
>> free.
>>
>
> Sure, it isn't free. I'm not suggesting that it is. But I am suggesting
> that it is a totally viable fallback strategy for this use case, and that
> the cost is negligible while still being non-zero.
>

+1. I hope I didn't sound like I was suggesting it was free :) Adding code
is never free.
The important question is whether it's actually affecting the bottom line
in a measurable way (which I think it won't).

Also, I think it's important to point out that this will be an optional
feature.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130719/18733ea2/attachment.html>