Windows is also IO bound - and performance under cygwin is especially bad. -Max
P T Withington wrote: > At least on my mac, it seems to be paging in all the inodes that > takes the time: > > [EMAIL PROTECTED] legals 23:12:03]$ time svn status > /dev/null > > real 1m11.149s > user 0m3.947s > sys 0m10.710s > [EMAIL PROTECTED] legals 23:13:38]$ time svn status -q > /dev/null > > real 0m5.224s > user 0m1.914s > sys 0m1.283s > [EMAIL PROTECTED] legals 23:13:56]$ time svn status > /dev/null > > real 0m11.778s > user 0m2.456s > sys 0m2.862s > [EMAIL PROTECTED] legals 23:14:16]$ time svn status -q > /dev/null > > real 0m4.252s > user 0m1.883s > sys 0m1.245s > [EMAIL PROTECTED] legals 23:14:33]$ time svn status > /dev/null > > real 0m3.994s > user 0m1.857s > sys 0m1.033s > > > > On 2006-07-10, at 19:08 EDT, Benjamin Shine wrote: > >> Yipes! >> >> svn status with no args does not contact the network at all. >> The empty-change-description task does "svn status -q" which *does* >> contact the network. >> Henry, try changing this line >> svn status -q >> $TMPFILE >> to just >> svn status >> $TMPFILE >> >> and see if that gives you a speedup. If it does, I can just grep >> out the ? and ! entries, which are hidden with the -q (quiet) >> argument. >> >> On Jul 10, 2006, at 1:04 PM, P T Withington wrote: >> >>> On 2006-07-10, at 14:37 EDT, Henry Minsky wrote: >>> >>>> The empty-change-description script where svn attempts to figure >>>> out what >>>> has changed, when run from the top level in an entire branch >>>> becomes >>>> unusably slow, at least under cygwin (> 20 minutes and counting >>>> on my >>>> thinkpad). >>>> Is there any way to speed this up? The workaround is to manually >>>> remember in >>>> roughly what subdirectories things are modified to cut down the >>>> search space, which isn't so bad, but >>>> it is nice sometimes to ask for a list of all modifications. >>> I have the same problem and I don't know a solution. AFAICT, it is >>> because svn doesn't maintain any central state on your machine so >>> must search the entire subtree to see if you've changed anything. I >>> haven't found a solution. It is partly why I made the svn tools be >>> driven off the change message, so at least you only have to search >>> the subtree once to compose the change message. After that, the file >>> list is taken from the change message. >>> >>> _______________________________________________ >>> Laszlo-dev mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev > > _______________________________________________ > Laszlo-dev mailing list > [email protected] > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
