<br><br><div class="gmail_quote">On Sat, Apr 7, 2012 at 1:45 AM, James K. Lowden <span dir="ltr"><<a href="mailto:jklowden@schemamania.org">jklowden@schemamania.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Fri, 6 Apr 2012 18:43:32 +0200<br>
Matthieu Monrocq <<a href="mailto:matthieu.monrocq@gmail.com">matthieu.monrocq@gmail.com</a>> wrote:<br>
> Le 6 avril 2012 00:49, James K. Lowden <<a href="mailto:jklowden@schemamania.org">jklowden@schemamania.org</a>> a<br>
> écrit :<br>
> > ><br>
</div><div class="im">> > > Yes I am using FUSE filesystems.<br>
> ><br>
</div><div class="im">> > I'm having trouble imagining a why a<br>
> > developer interested in speed would choose to keep source code (or<br>
> > object code) on anything except locally attached storage.<br>
><br>
</div><div class="im">> Editing code on a local PC but building and executing it on a server<br>
> farm (because it's much faster) is a common pattern I think.<br></div></blockquote><div>This is exactly the case here. However, If I put everything on tmpfs, latencies reduce to</div><div>~400ms to 600ms for error checking and roughly same for code completion.</div>
<div>I guess this is the best clang could probably do.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
</div>Granted, yes.<br>
<div class="im"><br>
> Then you have the choice of either keeping two copies of the code (one<br>
> local, one on the server) and then synchronizing before<br>
> compiling/running or to have them share their storage, one way or<br>
> another.<br>
<br>
</div>Sure.  And your experience (and mine) both point to optimizing for<br>
compilation.<br>
<br>
Because the number of files compiled will always equal or exceed the<br>
number edited, and because I/O is a bigger fraction of the compiler's<br>
performance than of the editor's (especially if we include the<br>
keyboard), best results will come from the compiler using local<br>
storage.<br>
<br>
You can edit over NFS or FUSE; you can use rsync; you can check in and<br>
have the build script check out.  ISTM any of those would be faster<br>
than encumbering the compiler I/O.<br>
<br>
Thanks for the explanation.  I see your motivation; I'm sure that even<br>
if there are "better" ways, the particular environment you're in may<br>
not be changed all that easily.  That said, optimizing away stat(2)<br>
calls would be a limited victory at best.  The only way to make<br>
compilation fast, in the end, is to arrange things such that it *can*<br>
be fast. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
--jkl<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Warm Regards,<br>Abhanshu<br>