From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24493 invoked by alias); 28 Apr 2015 15:19:54 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 34985 Received: (qmail 29768 invoked from network); 28 Apr 2015 15:19:53 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_PCNT autolearn=no version=3.3.2 Date: Tue, 28 Apr 2015 17:19:50 +0200 From: Vincent Lefevre To: zsh-workers@zsh.org Subject: Re: Filename generation: sorting by inode number Message-ID: <20150428151950.GB4973@ypig.lip.ens-lyon.fr> Mail-Followup-To: zsh-workers@zsh.org References: <20150425001719.GA12262@xvii.vinc17.org> <150425111451.ZM32010@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <150425111451.ZM32010@torch.brasslantern.com> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.23-6425-vl-r76280 (2015-03-04) On 2015-04-25 11:14:51 -0700, Bart Schaefer wrote: > On Apr 25, 7:11am, Mikael Magnusson wrote: > } > } Everything is possible with the "o" glob qualifier by virtue of the > } "e" specifier; > } zmodload -aF zsh/stat -b:stat b:zstat > } ls -Udi *(noe:'zstat -L -A REPLY +inode $REPLY:') > > That's why I asked about whether the hash-ordering affected efficiency > of stat(). Indeed: $ sudo drop-caches && time grep -q zzz 1000*(oN) grep -q zzz 1000*(oN) 0.03s user 0.32s system 0% cpu 40.726 total $ sudo drop-caches && time grep -q zzz 1000*(noe:'zstat -L -A REPLY +inode $REPLY:') grep -q zzz 1000*(noe:'zstat -L -A REPLY +inode $REPLY:') 0.06s user 0.14s system 12% cpu 1.590 total but "oc" is slower (confirmed by 3 tests each), even though the files have been created with no inode change, e.g.: $ sudo drop-caches && time grep -q zzz 1000*(oc) grep -q zzz 1000*(oc) 0.01s user 0.19s system 7% cpu 2.589 total The probable cause is the low ctime resolution (1 second?). > Although the inode number is available this way, we could > also get it from the dirent structure. Yes, this would be more efficient, but perhaps not noticeable. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)