nilshg
March 22, 2023, 10:11am
6
Somewhat old comment but potentially still relevant:
opened 11:31PM - 11 Aug 16 UTC
file system
# A brief description
As a Symfony developer, it's always been hard to get a st… able/fast development environment. My current setup is a Ubuntu running under VirtualBox (using vagrant). While page generation is fast, my IDE accesses my PHP files through SMB, which is really (sometimes horribly) slow.
I'm now trying to use WSL to improve all of this. However, I'm having a major performance issue when using `/mnt/*` folders.
If I set up a Symfony project under `/mnt/c`, it is really slow. If I set it up under `/home/mikael`, it is very fast.
# Expected results
Drives mounted under /mnt should be as fast a any other folder.
# Actual results
With a new Symfony 3.1.3 project, under `/home/mikael` takes between 100ms and 130ms to generate the home page.
The same project under `/mnt/c/` takes between 1200ms and 1500ms.
# Your Windows build number
10.0.14393.51
# Steps / commands required to reproduce the error
```
# Install PHP5
$ sudo apt-get install -y php5 php5-json
# Download Symfony installer
$ sudo curl -LsS https://symfony.com/installer -o /usr/local/bin/symfony
$ sudo chmod a+x /usr/local/bin/symfony
# Download Symfony
cd
symfony new symfony_test
# Start Symfony
cd symfony_test
php bin/console server:run
```
Open your browser and go to http://127.0.0.1:8000/.
Once the page is loaded, refresh it (on first request, Symfony had to generate its cache).
Generation time is displayed on the bottom left
![Image](http://glados.aperture.fr.nf/up/load/2016/08/2016-08-12_01-18-38.png)
You can then do the same under `/mnt/c/`
```
cd /mnt/c/
symfony new symfony_test
cd symfony_test
php bin/console server:run
```
# Additional information
I've added my dev folders as excluded folders in Windows Defender, as well as %LOCALAPPDATA%\lxss.
I've tried having my project in `~` and pointing my IDE to %LOCALAPPDATA%\lxss\home\mikael\ but as I've later read, there is no supported way of editing WSL files.
WSL is installed in its default location under C (no strange junction or symlink), which is a healthy SSD.
My computer is attached to a domain, if this might have any influence.
From there:
Linux has a top-level directory entry cache that means that certain queries (most notably stat calls) can be serviced without calling into the file system at all once an item is in the cache. Windows has no such cache, and leaves much more up to the file systems. A Win32 path like C:\dir\file gets translated to an NT path like ??\C:\dir\file, where ??\C: is a symlink in Object Manager to a device object like \Device\HarddiskVolume4. Once such a device object is encountered, the entire remainder of the path is just passed to the file system, which is very different to the centralized path parsing that VFS does in Linux.
Performance impacts in Julia have previously been discussed here:
My general sense is that Windows performance may get less attention than Linux performance. It seems much more likely that I’m the first one to recognize an issue on Windows. This could be merely because many of the developers and users of Julia tend to primarily work on Linux.
The exchange that Kristoffer linked above revealed an issue that was affecting Windows users more than Linux users. stat is regularly used when accessing a file since it determines basic information such as does the file…
2 Likes