[cfe-dev] Precompiled headers with libclang

Abhanshu Sharma abhanshu1 at gmail.com
Sun Apr 8 09:50:14 PDT 2012


On Sat, Apr 7, 2012 at 1:45 AM, James K. Lowden <jklowden at schemamania.org>wrote:

> On Fri, 6 Apr 2012 18:43:32 +0200
> Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote:
> > Le 6 avril 2012 00:49, James K. Lowden <jklowden at schemamania.org> a
> > écrit :
> > > >
> > > > Yes I am using FUSE filesystems.
> > >
> > > I'm having trouble imagining a why a
> > > developer interested in speed would choose to keep source code (or
> > > object code) on anything except locally attached storage.
> >
> > Editing code on a local PC but building and executing it on a server
> > farm (because it's much faster) is a common pattern I think.
>
This is exactly the case here. However, If I put everything on tmpfs,
latencies reduce to
~400ms to 600ms for error checking and roughly same for code completion.
I guess this is the best clang could probably do.

>
> Granted, yes.
>
> > Then you have the choice of either keeping two copies of the code (one
> > local, one on the server) and then synchronizing before
> > compiling/running or to have them share their storage, one way or
> > another.
>
> Sure.  And your experience (and mine) both point to optimizing for
> compilation.
>
> Because the number of files compiled will always equal or exceed the
> number edited, and because I/O is a bigger fraction of the compiler's
> performance than of the editor's (especially if we include the
> keyboard), best results will come from the compiler using local
> storage.
>
> You can edit over NFS or FUSE; you can use rsync; you can check in and
> have the build script check out.  ISTM any of those would be faster
> than encumbering the compiler I/O.
>
> Thanks for the explanation.  I see your motivation; I'm sure that even
> if there are "better" ways, the particular environment you're in may
> not be changed all that easily.  That said, optimizing away stat(2)
> calls would be a limited victory at best.  The only way to make
> compilation fast, in the end, is to arrange things such that it *can*
> be fast.


> --jkl
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 
Warm Regards,
Abhanshu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120408/e44b57d0/attachment.html>


More information about the cfe-dev mailing list