[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] responses to some IRC discussion of 'automate'
From: |
Nathaniel Smith |
Subject: |
Re: [Monotone-devel] responses to some IRC discussion of 'automate' |
Date: |
Sun, 6 Aug 2006 18:02:22 -0700 |
User-agent: |
Mutt/1.5.11+cvs20060403 |
On Mon, Aug 07, 2006 at 12:31:50AM +0200, Thomas Moschny wrote:
> On Monday 07 August 2006 00:12 Nathaniel Smith wrote :
> > > > Why should automate stdio block size be configurable?
> > >
> > > Because it is easier to make some measurements (you asked for some
> > > benchmarks when this came up last time) this way than to recompile
> > > x-times for different values of the constant ;-)
> >
> > Sure. (Though for simple measurement it often suffices to use a quick
> > getenv() type call, and commit it on a branch if you commit it at
> > all.)
>
> For this small change I doubt it would have been easier to get the value from
> the environment than from the commandline.
>
> Additionally, some quick tests show that there is no real optimum, but
> increasing performance with increased block size over a great range of block
> sizes.
>
> The ideal block size might depend on automate stdio's use: For a project like
> Guitone that only fetches metadata through this interface, a smaller block
> size will do, while projects like TracMonotone, that also fetches file
> contents, a big block size can really help to increase performance.
The only advantage of a small block size is that it puts a bound on
monotone's memory use.
Most of monotone's caches are sized at a few megabytes. I don't think
anyone will object to making the stdio block size larger than 1
kilobyte :-).
Actually, I guess there is some advantage in that if you basically
never hit the block size, it is easy for a client to have undetected
bugs in its block handling... but still.
> > Probably that's our job to adjust the default, then -- in practice I
> > can't imagine that the API's users can or will track this anywhere
> > near as well as we can.
>
> The average user won't use automate stdio anyway.
The "user" in this case is a tool developer; we still hope that there
will be many more of them than of us :-). And we should make it as
easy as possible for them to get good results out, without having to
learn every finicky detail of what's going on.
-- Nathaniel
--
"But suppose I am not willing to claim that. For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."
- [Monotone-devel] responses to some IRC discussion of 'automate', Nathaniel Smith, 2006/08/06
- Re: [Monotone-devel] responses to some IRC discussion of 'automate', Thomas Keller, 2006/08/06
- Re: [Monotone-devel] responses to some IRC discussion of 'automate', Nathaniel Smith, 2006/08/06
- Re: [Monotone-devel] responses to some IRC discussion of 'automate', Thomas Keller, 2006/08/07
- [Monotone-devel] Re: responses to some IRC discussion of 'automate', Bruce Stephens, 2006/08/07
- Re: [Monotone-devel] Re: responses to some IRC discussion of 'automate', Thomas Keller, 2006/08/07
- Re: [Monotone-devel] Re: responses to some IRC discussion of 'automate', Timothy Brownawell, 2006/08/07
- [Monotone-devel] Re: responses to some IRC discussion of 'automate', Bruce Stephens, 2006/08/07
- Re: [Monotone-devel] responses to some IRC discussion of 'automate', Timothy Brownawell, 2006/08/07