[distcc] Benchmarking the server-side cache. How bad is 4ms latency to distcc server?

[Dan Kegel]

On 2/5/06, Martin Pool <mbp at sourcefrog.net> wrote:
> You could combine it with the (currently disabled?) code that feeds the
> compiler from a fifo, so as to stream back errors or terminate
> compilation in the case of errors before the client finishes sending.

Gee, I didn't realize you could even do that.  Don't compilers like to
read the whole source before starting?

> However I suppose failing files are fairly rare, since they will
> generally terminate the build, and so not worth optimizing.

I agree.   The case I want to speed up is building correct files.

> This will probably require changing the client to a nonblocking setup
> where it can check for traffic back from the server while it keeps
> sending.   This is certainly possible, and will complicate it a bit but
> perhaps not too much.

I'll probably just pay the extra round trip for the moment to make the
client change easier to code.  I *have* been dying to rewrite all of
distcc's networking to really use nonblocking I/O and to allow multiple
simultaneous connections, but I'll continue resisting that urge as long
as possible.

> Incidentally, Van Jacobson's slides from linux.conf.au might be
> of interest to you.  It was a fascinating talk.
>
>   http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
>   http://vger.kernel.org/~davem/cgi-bin/blog.cgi/2006/01/27#vj_channels

Yes, indeed.  Something for the future, though.

> Will sending the hash first really be a problem?  I would have thought
> an extra round trip would be relatively cheap compared to the 2MB
> transmission, but I'm not sure.

I'm probably being overly perfectionistic.  Benchmarking will reveal whether
it's important.
- Dan

--
Wine for Windows ISVs: http://kegel.com/wine/isv