DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:mime-version
	:content-type:content-transfer-encoding; q=dns; s=default; b=pFh
	kn9Z5wkj3UnD4BDszp91ynwfcyVRojr3JQo8qxTgi3BcVsfWLdmf/pZjnPSmeeQU
	37nlR11wWnJDwvJRvsjiYJ1tfanwalCFVFB5xb2cE6scZ4nKh8gGCjfeAdQjyb1T
	sCzQ60DtYvHM6EE3y/S6q7LfbNvHDVRsAzUIYpRA=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
To: cygwin@cygwin.com
From: Achim Gratz <Stromeko@NexGo.DE>
Subject: Performance of "ls -F"
Date: Thu, 21 Jan 2016 15:44:48 +0000 (UTC)
Lines: 12
Message-ID: <loom.20160121T163405-489@post.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
User-Agent: Loom/3.14 (http://gmane.org/)

I am finding a large performance gap between plain "ls" and "ls -F" in a
directory with many files on a network share (NetApp disguised as NTFS if
that matters).  This has been there for quite a while, I've just now
realized what the reason was (I have "ls -F" as an alias for "ls" in my
interactive shells).  In a directory with 1300 files, a plain "ls" completes
in 0.3s, while "ls -F" requires about 95s.  Determining the file class seems
to require around 70...90ms per file, which I can confirm also for
directories with a lot less files.  What's involved in that determination
that takes such a long time?

Regards,
Achim.


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