X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76B303857C42
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1701835782;
	bh=3imd6nbKdfMC3w3c35Lot2i+hUPk119oEu95PbYQToc=;
	h=Date:Subject:To:List-Id:List-Unsubscribe:List-Archive:List-Post:
	 List-Help:List-Subscribe:From:Reply-To:From;
	b=l0Lq/f1F1WeMYfiN9Td/e8/33J8l+T6SK1vmdNlQiSyMcBhUNkkJxOw19O6ciYBti
	 5I4bES1E7shdSF5LIyizdwL3VZEok7eSrVOLqQJXGryVNk72YjVVMk+vKT14YJvbtX
	 05/di6ZkpEQl5zmp/YR16Zw0QaR76gp0EC6lx7K4=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B11873858037
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B11873858037
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701835769; cv=none;
 b=FhvZySz2aFio8SiLjkvEiKzkpewJZ1bbOpMUWYTh0PmKJB8jv1YsiRPj5ezHAvnaK0lqutt/IGVDJSJQizsuALlXfZMDS39Ln3Np731VLoCKK/IPkFC0Dyp5Bv6K62PcPz2kJ0NdVCHLbVxmMSJzQuWTcb+IOXHJ9gb6XHNzvYs=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1701835769; c=relaxed/simple;
 bh=jTfa7VzxSvW1E8jhkQFKWfXTJowrl26F/30UQcUOUoM=;
 h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
 b=QucRAzMKxj4OUVT1Kw2LH1sQbQqO8W5m1WzVA4TcJqeb64e9boB69vE1Bc/zvsYI5npjFWWgCOXfScI0OwwJg2RlL1afwpQ22iNkDizPY9jkq0cEqEcFhcT39m/7EGMasp6UgdXjgsYHyd1Z7cshqG1Gq8zYGfN1IP0xj9SIJHo=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1701835766; x=1702440566;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=+Gb77FtCn8yM5TJlAgFjx0uV1KPbM7eyLHypJ0JXZxo=;
 b=SHUzxDq1x/xp8EunuhL6pCo6W8iU+R2UPBD6D1AmARAjTWY8WfP7H17t+WI+HAlvu7
 FdZYRN64SQe1/wrs8AH5sONtATKasxxfXT/13IdnyXZrNgyRsMh6otBfo5zPOFpZZBQH
 nH9Xm/xTb8sFn1z/P8mmbZ16wn8yF44qq5j07tgknyQMwEDwD9p7HHuFHQh8CGBDxwuG
 wX/CjrhKdOkcZaN7g2oDq4haDqb1v2vcg/WUcl4vHeqyMZosdL/GL9NEAljwocpSRJr7
 4uM9cZpaga0SB47AhwG8z7U1dN76wKZtS3c/AdoShEEgIpIDj5i0hfVkGxr1sZewzFV7
 R7Jw==
X-Gm-Message-State: AOJu0YzME74uh3gXxZmqpbv95LFZPC9UdIso5WhmZC0D+hvMhzwhLdj9
 51unpTVcceB7/T8kp9jJwRroeqSsJITJ0Y6qEuSrzc29bpIKPhO2+XY=
X-Google-Smtp-Source: AGHT+IHElyujV1AAffCNgYRobgSp3volelXQ+Ee5bo6Npk1n5PQznAc9aVNaHxIvj181E+rQqPuP46VpVn/QuhURYL4=
X-Received: by 2002:a05:6512:39cb:b0:50b:f88b:1680 with SMTP id
 k11-20020a05651239cb00b0050bf88b1680mr137624lfu.34.1701835765665; Tue, 05 Dec
 2023 20:09:25 -0800 (PST)
MIME-Version: 1.0
Date: Wed, 6 Dec 2023 05:08:58 +0100
Message-ID: <CAAvCNcBZGepZMP9Q0D5ua+6ACftDOQEriqnuCbwg6umBPUA72Q@mail.gmail.com>
Subject: Catastrophic Cygwin find . -ls, grep performance on samba share
 compared to WSL&Linux
To: cygwin AT cygwin DOT com
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_05, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Level: *
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Dan Shelton via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Dan Shelton <dan DOT f DOT shelton AT gmail DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

Hello!
I am unhappy to report a severe performance issue with find -ls, ls -R
and grep -r, with Cygwin 3.4.9 and Cygwin 3.5.0 when samba shares are
involved.

Imagine a directory with 256 subdirs, and each has 256 files per
subdir, all on a samba share, samba server is on Linux with tmpfs.

mkdir dir1
for ((i=0;i<256;i++)) ; do
    mkdir "dir1/subdir$i"
    for ((j=0; j < 256;j++));do
        echo  "j=$j" >"dir1/subdir$i/j$j.txt"
    done
done

Time comparisations then show a dramatic difference, Debian Linux
accessing the samba share, WSL accessing the samba share, and Cygwin
accessing the samba share:
1. time find . >/dev/null
Cygwin 86 seconds
WSL 23 seconds
Debian 19 seconds

2. time find . -ls >/dev/null
Cygwin 129 seconds
WSL 38 seconds
Debian 32 seconds

3. time grep -r -E NOMATCH 2>/dev/null
Cygwin 390 seconds
WSL 144 seconds
Debian 141 seconds

So where does the bad Cygwin performance come from? Virus checker,
memory compression and other Windows services known to interfere with
benchmarking are OFF.

But the network trace shows a dramatic difference: While Debian and
WSL open files only once, the Cygwin run spends lots of network
traffic checking whether the txt files are txt.lnk, txt,bat.lnk and so
on, all non existent files.

Why does that happen?
-- 
Dan Shelton - Cluster Specialist Win/Lin/Bsd

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