Ahh, I thought the timings were based on the envvar that Stefan suggested to try. Thanks for clarifying.
On Tue, Nov 1, 2011 at 1:18 PM, <michael_rytt...@agilent.com> wrote: > Perhaps I wasn’t clear, the second set of runs where with a local working > copy instead of an nfs mounted working copy.**** > > ** ** > > *From:* Mark Phippard [mailto:markp...@gmail.com] > *Sent:* Tuesday, November 01, 2011 11:18 AM > *To:* RYTTING,MICHAEL (A-ColSprings,ex1) > *Cc:* s...@elego.de; users@subversion.apache.org > > *Subject:* Re: Apparent "svn rm" scaling problem in 1.7.x**** > > ** ** > > On Tue, Nov 1, 2011 at 1:10 PM, <michael_rytt...@agilent.com> wrote:**** > > LOL! I love the env variable. > > Here is some similar data for a local working copy. These are all run > with the env variable set. Again, svn rm is significantly slower than all > other operations. > > svn rm <file> 0.35s > svn st <file> 0.105s > svn blame 0.041s > svn unlock 0.056s > svn lock 0.053s > svn log 0.036s > svn info 0.014s**** > > ** ** > > But look how much it improved compared to how much the others improved? * > *** > > ** ** > > svn rm <file> 7s > svn add <file> 0.126s > svn st <file> 2s > svn blame <file> 0.2s > svn lock <file> 0.12s > svn unlock <file> 0.103s > svn log <file> 0.089s > svn revert <file> 0.133s > svn info <file> 0.074s**** > > ** ** > > Many of these commands are not even impacted by that variable. That said, > I do not get how this envvar can shave 7 seconds off the operation when it > usually only sleeps for a second.**** > > ** ** > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/**** > -- Thanks Mark Phippard http://markphip.blogspot.com/
