From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29389 invoked by alias); 28 Apr 2015 16:34:44 -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: 34987 Received: (qmail 13746 invoked from network); 28 Apr 2015 16:34:41 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=4d5GM9/3yxKhiu1fhG0mXtZF8vKQ8qPPoIxQzUCgoVM=; b=CfA/G2Ys9pUuA/nnzVyied9RyDMcJdTcq7Apv4kSuSNJzSVz7Q1P5vJHq2cXz25K2A OaOWg34fYgqfFVKTFwOaUTqTgsEK/jVDnmhqHoUOeOtr+ejCAd7ymEafRFBThaDltZIm fbYpHMFspMXWHtBcOwtwX8O+6z63y+Hrjd9/0LHneLJXqdvU2PMQg4fFC+uqtvqwJZhD fwE7R+PNW5Ww2Goi3pf5aSWoMPYr9a2M6t1/5YYmx1/TzZkYLdH/fQkChQSZ5k/FfNrW bEeFvI6+F+ZDIQb1eIJkmStjlX1fBAbu/PBT0YyjNf7qCmjzRF8b88uNOPRux29ztoLx t8Zg== X-Gm-Message-State: ALoCoQlhJVOlStYI6sHgkmQhH687/rBVxugiVpsAaTLAL5iRuWjCL9ZC3SCIH34yqbzUCUZtujDv X-Received: by 10.202.231.197 with SMTP id e188mr14333161oih.129.1430238878125; Tue, 28 Apr 2015 09:34:38 -0700 (PDT) From: Bart Schaefer Message-Id: <150428093435.ZM30556@torch.brasslantern.com> Date: Tue, 28 Apr 2015 09:34:35 -0700 In-Reply-To: <20150428151950.GB4973@ypig.lip.ens-lyon.fr> Comments: In reply to Vincent Lefevre "Re: Filename generation: sorting by inode number" (Apr 28, 5:19pm) References: <20150425001719.GA12262@xvii.vinc17.org> <150425111451.ZM32010@torch.brasslantern.com> <20150428151950.GB4973@ypig.lip.ens-lyon.fr> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Filename generation: sorting by inode number MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii [Sorry for the long context / short reply below] On Apr 28, 5:19pm, Vincent Lefevre wrote: } } $ 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?). Looks like (oc) is significantly faster than (oN), though, even though it is slower than (o+byinode). So it may be a reasonable compromise.