<br><br><div class="gmail_quote">Le 6 avril 2012 00:49, James K. Lowden <span dir="ltr"><<a href="mailto:jklowden@schemamania.org">jklowden@schemamania.org</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, 4 Apr 2012 14:41:55 +0530<br>
Abhanshu Sharma <<a href="mailto:abhanshu1@gmail.com">abhanshu1@gmail.com</a>> wrote:<br>
<br>
> > Do you have a benchmark that clearly shows how much time is spent on<br>
> > 'stat' here? Are you using a network filesystem that makes stat<br>
> > system calls slow for some reason?<br>
> ><br>
> Yes I am using FUSE filesystems.<br>
<br>
Why??<br>
<br>
It's an earnest question.  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.  Putting<br>
a network and/or userspace between the compiler and the source code is<br>
a recipe for poor productivity.<br>
<br>
Modern source-control systems replaced CVS partly because CVS's design<br>
presumes expensive storage (which was true when CVS was young).<br>
Subversion explicitly chose to prefer local storage to network I/O<br>
whenever feasible because disk storage is now cheaper than water.  git<br>
took that design one step further, keeping the whole repository local.<br>
<br>
But you surely know all that.  Whatever could require you to ignore<br>
it?<br>
<br>
--jkl<br></blockquote></div><br>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.<br><br>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.<br>
<br>-- Matthieu<br>