delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2007/01/13/13:19:24

X-Spam-Check-By: sourceware.org
Date: Sat, 13 Jan 2007 19:18:59 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Snapshot speed on managing files
Message-ID: <20070113181859.GA5595@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <62410 DOT 52144 DOT qm AT web25001 DOT mail DOT ukl DOT yahoo DOT com> <20070112102454 DOT GA8311 AT calimero DOT vinschen DOT de> <Pine DOT CYG DOT 4 DOT 58 DOT 0701121033010 DOT 320 AT PC1163-8460-XP DOT flightsafety DOT com>
Mime-Version: 1.0
In-Reply-To: <Pine.CYG.4.58.0701121033010.320@PC1163-8460-XP.flightsafety.com>
User-Agent: Mutt/1.4.2.2i
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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.


Corinna

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

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019