On 12.03.2011 19:41, Mark Phippard wrote: > On Sat, Mar 12, 2011 at 12:49 PM, Justin Erenkrantz > <jus...@erenkrantz.com> wrote: >> On Fri, Mar 11, 2011 at 4:11 PM, Mark Phippard <markp...@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
