Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows: Investigate writing native library / command line tool for file traversal #11182

Closed
bpasero opened this issue Aug 30, 2016 · 9 comments
Assignees
Labels
search Search widget and operation issues

Comments

@bpasero
Copy link
Member

bpasero commented Aug 30, 2016

Testing #11035

  • open a path in VS Code using UNC loopback (e.g. \localhost\c$\GitDevelopment\vscode)
  • quick open to find a file

=> it takes a lot longer compared to our raw node.js solution in 1.4
=> maybe we need to detect UNC cases and avoid using dir command

@bpasero bpasero added bug Issue identified by VS Code Team member as probable bug search Search widget and operation issues labels Aug 30, 2016
@bpasero bpasero changed the title Windows: major performance degredation searching on a UNC drive Windows: major performance degredation searching on a UNC/network drive Aug 30, 2016
@bpasero bpasero added the important Issue identified as high-priority label Aug 30, 2016
@bpasero
Copy link
Member Author

bpasero commented Aug 30, 2016

I am seeing the same when opening a folder that is mapped into Windows from the Parallels host (Mac). Since this seems like a more typical use case, I am marking this one as important.

@chrmarti
Copy link
Collaborator

The Parallels case seems to work for me. I've opened, e.g.: \psf\Home\Development\repos\target

@chrmarti
Copy link
Collaborator

Ah...both work, I need to investigate the performance.

@bpasero
Copy link
Member Author

bpasero commented Aug 31, 2016

@chrmarti shouldn't you be on vacation :)? My suggestion for the windows issues is to go back to the node.js search for this release on Windows only and then revisit in September with a different solution.

@chrmarti
Copy link
Collaborator

Bummer, dir doesn't perform well with these high latency cases. (Measured on Parallels myself now.)

I agree, we should revert. Longer term we might just detect UNC paths and fall back. The bigger problem might be the long paths (#11183) and circular symlinks (#11179), since we can't detect these upfront. Even detecting these from the output of dir might not be trivial, because the only hint is a message about a path being too long on stderr that might get translated (I need to check that though).

(12 hours behind you in the middle of the Pacific :)

@bpasero
Copy link
Member Author

bpasero commented Aug 31, 2016

@chrmarti I can add a check for windows and use the old node.js approach. From testing it seems there are no such issues on Mac and Linux.

I do think that for Windows we should look into writing C#/C++ command line tool to handle this (similar how we do for the Windows file watcher). E.g. leveraging Directory.GetFiles. There does not seem to be a way to prevent dir from running into symlink loops.

Detecting UNC paths is not enough because you can also map a network drive as a real drive letter, so the path is not telling about the nature of the connection. Again, a native solution might help us identify such circumstances.

@bpasero bpasero removed the important Issue identified as high-priority label Sep 3, 2016
@chrmarti
Copy link
Collaborator

We reverted to use the existing tree traversal in node.js (#11293). Closing bugs due to the use of 'dir' as duplicates of this one.

@chrmarti chrmarti changed the title Windows: major performance degredation searching on a UNC/network drive Windows: Investigate writing native library / command line tool for file traversal Sep 19, 2016
@chrmarti
Copy link
Collaborator

Moving this out from the September release due to its scope.

@chrmarti chrmarti added this to the Backlog milestone Sep 26, 2016
@chrmarti chrmarti removed the bug Issue identified by VS Code Team member as probable bug label Nov 30, 2017
@chrmarti chrmarti removed this from the Backlog milestone Nov 30, 2017
@chrmarti
Copy link
Collaborator

Using ripgrep now.

@vscodebot vscodebot bot locked and limited conversation to collaborators Jan 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
search Search widget and operation issues
Projects
None yet
Development

No branches or pull requests

2 participants