It is an Intel Core i7-6700HQ@2.6GHz, 16GB memory, SanDisk SD7SN6S-512GB SSD(SATA), running build 17134.81 (v. 1803, a.k.a. the April update). Perhaps my expectations were not very high, I didn't measure the time taken precisely enough, but it seemed the extraction took most of the time. I have since tried to run some benchmarks; couldn't wait for filebench to complete (maybe I've selected the wrong configuration, but I suspect it was worse than that), bonnie++ ran though, with a result which seemed to me the reverse to what is in that discussion - it completed much faster when the work directory was /mnt/c/Temp than when it was just /tmp. The resulting figures were not conclusive - some of the metrics favoured /tmp, some - /mnt/c/Temp, e.g. random file deletion was much faster when crossing the /mnt boundary.
The discussion in that thread was quite illuminating with respect to the problems Microsoft developers have with WSL, and, to be honest, it would be harsh to expect much more. It, after all, was thought of as a means of keeping developers stay with Windows while using a number of open source technologies, not for actual deployment in the wild.
Chavdar
What are your hardware specs? I suspect you have both a faster machine
and more patience than I do.
I agree that WSL and Cygwin are fast enough for many purposes.
wouldn't want to build gcc under WSL on the machine I have, though.
For comparison, I ran auto-pkgsrc-setup on 3 identical machines running
different Unix OSs. These are old PowerEdge 1920 servers, 4-core Xeon
5160 3.0GHz, 16G RAM.
CentOS MD-RAID mirror 6:16
FreeBSD Root-on-ZFS 5:57
NetBSD PERC RAID 12:56 (I'd like to know what the
bottleneck was here, I'd expect NetBSD to be on par with the others)
zile build on NetBSD 7:10
....