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

[Sean Silva]

On Fri, Jul 19, 2013 at 2:29 AM, Manuel Klimek <klimek at google.com> wrote:

> 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).
>
>
As a simple test of the overhead, I modified the clang driver to (at the
beginning of main) open a lock file "/Users/sean/tmp/clang.lock" (in a
blocking manner) and write "foo\n" to the file, then close the file. My
hardware is a dual socket quadcore xeon mac pro with hyperthreading (2
sockets x 4 cores x 2 threads = 16). I built an LLVM release build
(CMake+ninja) with both an unmodified and modified clang.

My findings were that this does not have a noticeable effect on compilation
time in this particular setup. Since a blocking locked write is a sort of
"worst case", I think that (extrapolating a bit) at least for local builds,
the effect of file locking is likely insignificant.

-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130719/205212da/attachment.html>