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 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

Ok, obviously I needed a testcase to see the speed improvement of this
method.  So I came up with this one:

  $ cat > << EOF
  echo -n "Creating files... "
  for d in `seq -w 1 32`
    mkdir dir$d
    for f in `seq -w 1 32`
      dd if=/dev/zero of="dir$d/file$f" bs=64K count=16 >/dev/null 2>&1
  echo "Ok."
  echo -n "Deleting files ..."
  time rm -rf dir*
  $ chmod +x ./

Ok, next thing is taking the time with the current implementation
which always moves the file to the bin:

  $ ./
  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:

  $ ./
  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.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

Unsubscribe info:
Problem reports:

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