I/O to/from /dev/zero or /dev/null could be special-cased.
Benchmarking file system performance can be fraught.
--
-Barry Shein, co-author of nfsstones benchmark
Software Tool & Die| b...@theworld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1
On 10/29/2021 11:44 AM, Adam Dinwoodie wrote:
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
There are a bunch of different possibilities
(*) temporary files - there was an improvement here in recent cygwin versions which means that if your machine has lots
of memory and your program creates lot of temporary files, then it will now be significantly faster
(*) file name lookup - linux
On Fri, 29 Oct 2021 at 10:36, Eliot Moss 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
Sorry, it could depend on what we mean by "file access", so allow me to try to
clarify. I am grateful of your data since they show that raw data handling
speed is good. But to read a file you have to open it. I suspect that file
lookup and opening may be an issue. Which remains me, I should
On Fri, 29 Oct 2021 10:35:08 +0100
Eliot Moss 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
Dear Cygwiners -
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
7 matches
Mail list logo
