Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

File picker is really slow on huge projects #10881

Closed
liquidev opened this issue Jun 4, 2024 · 4 comments
Closed

File picker is really slow on huge projects #10881

liquidev opened this issue Jun 4, 2024 · 4 comments
Labels
C-bug Category: This is a bug

Comments

@liquidev
Copy link

liquidev commented Jun 4, 2024

Summary

I just tried editing the Unreal Engine source code with Helix, and fing into an arbitrary file from my project. Unfortunately it seems like Helix indexes the entire source directory recursively from scratch every time you open the file picker, which results in unacceptably slow performance in a huge codebase like Unreal Engine's. (As of typing this I typed in the name of the file I'd like to open, and the file picker still hasn't indexed my file.)

This is also compounded by Helix indexing directories that are listed in the .ignore file. It seems like .ignore just results in files matching any of the globs being hidden from the view, rather than preventing recursion.

Reproduction Steps

  1. Open a compiled Unreal Engine in Helix (since it has way more files than just the cloned source code)
  2. f
  3. Search for a file such as EdGraphPin.cpp

Helix log

Irrelevant since this is strictly a performance issue.

Platform

Windows

Terminal Emulator

Windows Terminal

Installation Method

winget

Helix Version

helix 24.3 (2cadec0)

@liquidev liquidev added the C-bug Category: This is a bug label Jun 4, 2024
@the-mikedavis
Copy link
Member

The log isn't irrelevant, this line might be insightful:

log::debug!("file_picker init {:?}", Instant::now().duration_since(now));

Can you provide a simpler reproduction case - a different similarly large project? Cloning unreal engine is convoluted

@pascalkuthe
Copy link
Member

Our transversal is currently not parallel because we sort entries alphabetically.

Windows has super slow IO. Anytime I see people having issues with IO speed like this it's Windows (if you are on WSL its even worse still) on Linux/macos it's never an issue for projects of practical size (I work on massive legacy codebases).

We can likely offer an option to disable the sorting and allow parallel transversal. It's not too useful since it's only a secondary tie breaker as soon as you enter a query.

Caching the filesystem does not make sense. For small directories it's not necessary and for large directories the memory consumption is prohibitive (you wouldn't want to cache $HOME or /).

And .ignore does prevent entering directories if a glob matches a directory

@markstos
Copy link
Contributor

markstos commented Jun 6, 2024

Can you provide a simpler reproduction case - a different similarly large project?

The Linux kernel is often used when people need a huge project to test with.

I just tried untar'ing this tarball of 85,000 files and then opening hx in the directory:

https://git.kernel.org/torvalds/t/linux-6.10-rc2.tar.gz

It opened instantly. On Linux.

@RoloEdits
Copy link
Contributor

RoloEdits commented Jun 8, 2024

@liquidev One thing you can try is the new dev drive (built on top of ReFS) windows 11 comes with (you didn't specify windows version, so assuming 11). I've noticed various I/O improvements myself. Your milage may vary.

link: https://learn.microsoft.com/en-us/windows/dev-drive/

@kirawi kirawi converted this issue into discussion #10995 Jun 20, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
C-bug Category: This is a bug
Projects
None yet
Development

No branches or pull requests

5 participants