This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Snapshot speed on managing files


On Sat, 13 Jan 2007, Corinna Vinschen wrote:

> On Jan 12 10:34, Brian Ford wrote:
> > On Fri, 12 Jan 2007, Corinna Vinschen wrote:
> >
> > > Current CVS contains a change which is probably the cause for that.
> > > Before deleting a file, the file is moved to the recycle bin.
> >
> > Couldn't we make this conditional only if a "regular" delete fails because
> > the file is in use?  Would it then only penalize deletes of open files?
> >
> > (Incidentally, I've noticed this as well.)
>
> I have to pick up the thread at this point again because...
>
> ... because I was just implementing what Dave was asking for.  What I'm
> trying to do now is to open the file with the sharing flags set to all-zero.
> If I get a sharing violation I know the file is in use and should be
> moved to the bin.   If opening the file worked I can just close the
> handle again and the file will be deleted immediately (delete-on-close
> semantics).
>
> Ok, obviously I needed a testcase to see the speed improvement of this
> method.  So I came up with this one:
>
>   $ cat > deltest.sh << EOF
>   #!/bin/sh
>   echo -n "Creating files... "
>   for d in `seq -w 1 32`
>   do
>     mkdir dir$d
>     for f in `seq -w 1 32`
>     do
>       dd if=/dev/zero of="dir$d/file$f" bs=64K count=16 >/dev/null 2>&1
>     done
>   done
>   echo "Ok."
>   echo -n "Deleting files ..."
>   time rm -rf dir*
>   EOF
>   $ chmod +x ./deltest.sh
>
> Ok, next thing is taking the time with the current implementation
> which always moves the file to the bin:
>
>   $ ./deltest.sh
>   Creating files... Ok.
>   Deleting files ...
>   real    0m2.546s
>   user    0m0.233s
>   sys     0m0.578s
>
> Huh?  2.5s for what Marco tells us needs 1m40 on his machine?
>
> Anyway, let's try with the new implementation:
>
>   $ ./deltest.sh
>   Creating files... Ok.
>   Deleting files ...
>   real    0m2.359s
>   user    0m0.187s
>   sys     0m0.531s
>
> Can anybody explain to me why moving to the bin should take that
> long on another machine?  Apparently the performance hit is barely
> visible on my machine.  It's hardly worth to change the code.
>
> Maybe I'm just "suffering" from caching effects?  I added a really long
> `find' run between creating and deleting the files, but that made the
> results in both variations even better!  1.4s vs. 1.2s.
>
> So, what's up on the slow machines?  Virus checker?  But why should an
> open/close sequence not be hit by a virus checker, while an open/move/
> close sequence gets hit that badly?  I don't quite get it.

Does <http://cygwin.com/ml/cygwin/2007-01/msg00383.html> seem like a
plausible answer?  I'm just reiterating it because it may have been lost
among other suggestions in this thread.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Freedom is just another word for "nothing left to lose"...  -- Janis Joplin

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]