On 12.03.2011 19:41, Mark Phippard wrote:
> On Sat, Mar 12, 2011 at 12:49 PM, Justin Erenkrantz
> <justin_at_erenkrantz.com> wrote:
>> On Fri, Mar 11, 2011 at 4:11 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>>> I think we have to get this work done soon. We cannot release with
>>> performance like it is. How do we define the scope of the work that
>>> needs to be done so that we can divide and conquer and get these
>>> changes in place?
>> It sounds like we should codify what our performance targets are.
>>
>> What are the operations (and test cases?) that are important to us? -- justin
> I agree that we will have to codify this.
>
>> Is it acceptable if 1.7 is as fast as 1.6? Should it be faster?
>> Could we accept a slowdown for 1.7 as long as we know how we can get
>> it on par (or faster) for 1.8?
> I think it should be faster overall. Like Ivan, I think status and
> update on large working copies are areas where I would like to see
> show significant improvements.
>
> I can live with some operations being comparable to 1.6. I do not
> think we can accept any major regressions in performance. It looks
> like checkout is currently a major regression (but we should try to
> codify that). It definitely looks like NFS mounted working copies is
> a major regression. I do not think we can ship without getting those
> back to 1.6 levels.
>
> CPU usage is also way higher which might yield regressions that are
> harder for us to quantify with benchmarks. I think we can only keep
> an eye on that and hope it comes down as we make improvements to
> overall performance.
I have a feeling that all of these concerns -- CPU usage, speed in
general and especially speed over NFS -- will be solved by the "simple"
expedient of issuing a lot less transactions per operation. By a lot
less, I mean not proportional to WC size.
-- Brane
Received on 2011-03-13 08:09:42 CET