X-Recipient: archive-cygwin AT delorie DOT com
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EBC7C3858410
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=dinwoodie.org
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dinwoodie.org
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=dinwoodie.org; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=VIDr82WVl/6gjQhnYeKLptqFup9rzj8QLZC86c5ipGM=;
 b=Gzuiv0SGkk+pX+wqLO+InFbBSV4PhEXPJjj8jakqeRbknTXZMDSCYfhgKW//LrdGCU
 nLGm5BLu7C8NC5CIzJEAYwB3fNvgbiLTsDWgVj1LG2hAqYwWt/480wwK0UORlj14NTWC
 42UsoRFOzPbC1RPNxxOk3aac+unaGdWqfP1Lk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=VIDr82WVl/6gjQhnYeKLptqFup9rzj8QLZC86c5ipGM=;
 b=j4yIXCG2cvm3OX6X8XrIgCx0i8dWMg9X/jxWV1rDE1g/MbyZvChzO6UUcIqtkkcvEG
 Knbz1x81HWZnrmiYlTvmHbQFji1nlADo6GpbovwOR7yqxskdalmG20/7i0hnXVep3qc3
 E1MbqrfchAWuWUQVqUVL1QtGe6EfHPQ1uJS0mTl9uq9MX6Grqe+9Q9UXKG7G2eHHh+eP
 cu/oBPrbfxgR9Gy7w3/Ez8rNeQW2fj8pcacHbwHDqUgw/E2pMP9xaxStN/RxcmFrUqlC
 9s4MOCwpAf1llq2nGTPGi/R3c4Xpe/LdBGHoVAVMcWC2wZWFXP9NadK966DQ5v50xb//
 vRjg==
X-Gm-Message-State: AOAM530cfyNx1e/DbFeJTES9p4foZHw59617q+39/4EkxTDL04agPrZh
 u/s/LDS+YKAeYcLFBtD0054PDvrUmcMbfuAFfzztFLtNMC4=
X-Google-Smtp-Source: ABdhPJyJGqhCpDHd6HoqeiAKPVD419WKf1m2u6ufOqXYsYKC331sVJGt2Ljs37Iwim3dDDOq0B0ByEMAY3KpYWzIgL8=
X-Received: by 2002:a25:b294:: with SMTP id k20mr8160054ybj.232.1635504316554; 
 Fri, 29 Oct 2021 03:45:16 -0700 (PDT)
MIME-Version: 1.0
References: <00895c47-8df9-1f17-baac-0b3560de9d1c AT cs DOT umass DOT edu>
In-Reply-To: <00895c47-8df9-1f17-baac-0b3560de9d1c@cs.umass.edu>
From: Adam Dinwoodie <adam AT dinwoodie DOT org>
Date: Fri, 29 Oct 2021 11:44:40 +0100
Message-ID: <CA+kUOamNpqUSnFOnnd0SdSZJj7uohG6LaDL4jz95cttbM8XDVQ@mail.gmail.com>
Subject: Re: Curiosity about file access performance
To: cygwin <cygwin AT cygwin DOT com>
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,
 SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on
 server2.sourceware.org
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Fri, 29 Oct 2021 at 10:36, Eliot Moss <moss AT cs DOT umass DOT edu> wrote:
> I think a lot of us know that fork() under Cygwin is slower than on Linux and
> have some grasp of why.  But I have noticed that file access is rather lower
> under Cygwin as well.  My "poster child" for this is running latex.  I am
> working on writing a book, which includes a huge number of LaTeX style files
> and such.  Under WSL1 (which has the same fork cost issues as Cygwin for
> similar reasons), reading the style files goes by in little more than the
> blink of an eye (about 1 sec), while on Cygwin it takes a little over 17 seconds.
>
> The time to process the body of the book is 23 seconds under WSL1 and 35 under
> Cygwin.  So the total times are 53 seconds under Cygwin and 24 under WSL1.  I
> believe the LaTeX installations are the same versions, and I get the same
> outputs.  Both LaTeX's are 64 bit programs.  There is not much forking here
> (at least I don't believe there is, but maybe there is under the cover for
> doing things with pdf figures or something), but a fair amount of file I/O.
>
> For many / most things, the Cygwin overhead is tolerable; for running this
> book, since I will be doing it over and over, it was worth investing in
> getting everything set up on WSL1.
>
> But it got me wondering as to why?

AIUI it's a fundamental part of the trade-offs that NTFS makes:
compared to common Linux file systems like ext4, NTFS is much slower
at things like parsing directory structures (which is a necessary part
of opening any given file). In the same way that native Windows
programs tend to use threading implementations that work differently
to fork(), native Windows applications will also often much prefer
large monolithic data files, where native *nix applications are much
more likely to have lots of small files. As a result, for things that
require opening lots of files, WSL (at least if you're using the
native WSL disk, which will be a *nix disk image stored in a file,
rather than files under /mnt/c or similar) will likely be quicker than
a similar operation through Cygwin, as Cygwin will always be affected
by those NTFS overheads.

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