From: Kaz Kylheku <kaz@kylheku.com>
To: Dan Shelton <dan.f.shelton@gmail.com>
Cc: cygwin@cygwin.com
Subject: Re: Catastrophic Cygwin find . -ls, grep performance on samba share compared to WSL&Linux
Date: Wed, 20 Dec 2023 09:20:23 -0800 [thread overview]
Message-ID: <07c7379e983c9f436ebf86e3818ca843@kylheku.com> (raw)
In-Reply-To: <CAAvCNcB0_0ZeujP23QZFZaDvVTh5rxbXJw4FP6uXNPErCgdZ2w@mail.gmail.com>
On 2023-12-17 22:22, Dan Shelton via Cygwin wrote:
> It would be nice if someone from the Cygwin authors could assist me in
> figuring out why this happens.
Cygwin is famously slow; this is nothing new. We are grateful
for Cygwin because it makes stuff work at all; if it were blazing
fast that would be a bonus.
E.g. git operations (clone, rebase, ...); ./configure scripts; ...: all
run like molasses.
The following is just my fast and loose opinion, shot from the hip,
and possibly off or wrong, but it likely has to do with the layering.
Cygwin's core API is based on a C library called Newlib. Cygwin bolts
Newlib to Windows by means of an additional shim below Newlib that
is based on C++ objects, where there is path munging going on and such,
and that's where the Win32 calls get made. It's an additional abstraction.
I worked with the internals a bit when producing the Cygnal
project.
next prev parent reply other threads:[~2023-12-20 17:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-06 4:08 Dan Shelton
2023-12-18 6:22 ` Dan Shelton
2023-12-18 6:49 ` Marco Atzeri
2023-12-18 6:53 ` Dan Shelton
2023-12-18 7:05 ` Marco Atzeri
2023-12-18 7:16 ` Dan Shelton
2023-12-18 8:23 ` Marco Atzeri
2023-12-20 17:20 ` Kaz Kylheku [this message]
2023-12-21 12:16 ` rfe: CYGWIN fslinktypes option? " Martin Wege
2023-12-21 16:10 ` Cedric Blancher
2023-12-21 17:43 ` Brian Inglis
2023-12-21 20:32 ` Kaz Kylheku
2023-12-24 0:47 ` Roland Mainz
2024-01-08 14:53 ` Corinna Vinschen
2023-12-22 18:53 ` Andrey Repin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=07c7379e983c9f436ebf86e3818ca843@kylheku.com \
--to=kaz@kylheku.com \
--cc=cygwin@cygwin.com \
--cc=dan.f.shelton@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).