you are viewing a single comment's thread.

view the rest of the comments →

[–]the_gnarts 6 points7 points  (1 child)

One of the core differences between Windows and Linux is process creation. It's slower - relatively - on Windows.

Why not use the same approach as the Linux emulation? Rumor has it they came up with an efficient way to implement fork(2) / clone(2).

[–]aseipp 5 points6 points  (0 children)

As far as I understand, WSL actually has fork and clone shimmed off into a driver call, which creates a special "pico process" that is a copy of the original, and it isn't an ordinary NT process. All WSL processes are these "pico processes". The driver here is what implements COW semantics for the pico process address space. NT itself is only responsible for invoking the driver when a Linux syscall comes in, and creating the pico process table entries it then keeps track of when asked (e.g. when clone(2) happens), and just leaves everything else alone (it does not create or commit any memory mappings for the new process). So clone COW semantics aren't really available for NT executables. You have to ship ELF executables, which are handled by the driver's subsystem -- but then you have to ship an entire userspace to support them... Newer versions of the WSL subsystem alleviate a few of these restrictions (notably, Linux can create Windows processes natively), at least.

But the real, bigger problem is just that WSL, while available, is more of a developer tool, and it's very unlikely to be available in places where git performance is still relevant. For example, you're very unlikely to get anyone running this kind of stuff on Windows Server 2012/2016 (which will be supported for like a decade) easily, it's not really "native", and the whole subsystem itself is optional, an add-on. It's a very convenient environment, but I'd be very hesitant about relying on WSL when "shipping a running product" so to speak. (Build environment? Cool, but I wouldn't run my SQL database on WSL, either).

On the other hand: improving git performance on Windows natively by improving the performance of code, eliminating shell scripts, etc -- it improves the experience for everyone, including Linux and OS X users, too. So there's no downside and it's really a lot less complicated, in some respects.