0

Can someone explain the parse time difference between Windows shell and WSL2 under the same system below when running the same command under the same project?

As you can see there are also some differences in Files, Lines etc. Is there any way to speed up the WSL2 parse time?

tsc -project ./tsconfig.json --diagnostics

Windows 10 shell (tsc version 3.1.2)

Files:          139
Lines:        35528
Nodes:       150245
Identifiers:  49306
Symbols:      38212
Types:         2460
I/O read:     0.05s
I/O write:    0.01s
Parse time:   0.74s
Bind time:    0.13s
Check time:   0.48s
Emit time:    0.13s
Total time:   1.48s

WSL2 Ubuntu 18 LTS under the same system (tsc version 4.1.4)

Files:             175
Lines:           39622
Nodes:          161997
Identifiers:     56416
Symbols:         40823
Types:            2795
Instantiations:  12267
Memory used:    76663K
I/O read:        1.13s
I/O write:       0.16s
Parse time:     14.45s
Bind time:       0.36s
Check time:      0.39s
Emit time:       0.32s
Total time:     15.52s
Fredrik C
  • 570
  • 6
  • 22
Maverick
  • 1,105
  • 12
  • 41

1 Answers1

0

This is very likely due to the very poor file performance in WSL2 for windows drives (everything under /mnt). See the bug report for WSL2 here: https://github.com/microsoft/WSL/issues/4197

There could be some workarounds, the major one to me would be using WSL1 if you need to build from Linux on your machine.

Fredrik C
  • 570
  • 6
  • 22
  • Thanks, I had some problems with wsl1 and docker, so I decided to move on with wsl2. I suppose there is nothing I can do, right? – Maverick Feb 10 '21 at 19:50
  • You should be able to use a native Linux partition where you have another clone of your repository, that should avoid the problem. – Fredrik C Feb 12 '21 at 07:21
  • Thanks! This is not a feasible solution for me currently. So, I tried another scenario. The scenario I tried is to run servers (using SSL) under WSL2 & just one server (for development purposes) in native Windows for speedup. While using 127.0.0.1:3001 I get "connection refused" in the [::1]:3001 it works. Both 127.0.0.1 and [::1] are indicating to a fake local domain example.com under my host's file. In the ipv6 case unfortunately I get the error "Only absolute URLs are supported" under my win server. Trying with the fake domain example.com:3001 I get again "connection refused". Any advice? – Maverick Feb 12 '21 at 10:01
  • ok solved. Calling just ::1:3001 (without brackets) is failing but calling with [::1]:3001 works. The main question remains. Why with ipv4 127.0.0.1:3001 fail but instead with [::1] work? Both of them are the localhost. My windows server resolves localhost to 127.0.0.1 – Maverick Feb 12 '21 at 10:16
  • It seems like there are some issues with localhost in WSL. I am not sure if it is https://github.com/microsoft/WSL/issues/4851 that you see or not, it might be – Fredrik C Feb 12 '21 at 10:29