[cfe-dev] Precompiled headers with libclang
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
> 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
> 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.
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev