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

[Feature] Don't try to scan all files on open #544

Closed
Rizhiy opened this issue Sep 27, 2022 · 7 comments
Closed

[Feature] Don't try to scan all files on open #544

Rizhiy opened this issue Sep 27, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@Rizhiy
Copy link

Rizhiy commented Sep 27, 2022

Is your feature request related to a problem? Please describe.
I have a project which has a data folder.
There are quite a lot of files in the data folder ~500k
When I first open coc-explorer, it takes something like 10 sec to open, which is annoying.

Describe the solution you'd like
Since this doesn't happen in other project, I suspect the problem is that coc-explorer tries to build the whole file tree on first open.
This seems pointless, since most of the time people don't even open most of their folders during normal use.
Instead, the file tree should be evaluated lazily when each particular directory is expanded.

Describe alternatives you've considered
I guess another solution would be to have some kind of ignore system, but that would require extra work on the part of a user, which is suboptimal.

@Rizhiy Rizhiy added the enhancement New feature or request label Sep 27, 2022
@weirongxu
Copy link
Owner

The explorer doesn't read file contents when opening a directory. and doesn't traverse all the folders, it only traverses them when user use gl to expand them.

But I suspect that reading file information will cause slower loading (like link, executable, writable, readable).

I have to refactor this part of the code to make the explorer support lazy loading of this information.

Perhaps related #535

@Rizhiy
Copy link
Author

Rizhiy commented Sep 28, 2022

My data is actually 4 folders deep from the root directory, so something is being done recursively.

When I'm in the root directory, most commands are very quick, here are the timings:

  • lsd -alh 0,00s user 0,00s system 93% cpu 0,003 total
  • du -sh * 0,18s user 0,39s system 99% cpu 0,567 total
  • git status 0,00s user 0,00s system 90% cpu 0,003 total
    Not sure what information explorer is looking up, but it should take so long.

@Rizhiy
Copy link
Author

Rizhiy commented Sep 28, 2022

I made a quick script which should reproduce the problem:

mkdir explorer-test
cd explorer-test
mkdir -p dir1/dir2/dir3/dir4
for idx in {1..100000}; do
    touch dir1/dir2/dir3/dir4/"$idx".txt
done
touch tmp.txt
vim tmp.txt

As mentioned in #535, vim freezes on first open. But if you close (^C) it and open vim again, it works normally but explorer takes a long time to open.

@weirongxu
Copy link
Owner

Sorry for the delay in replying. do you mean it will freeze when expanding dir1?

This is a feature that automatically expands a single folder. You can avoid expanding single directories by set explorer.autoExpandMaxDepth to 1, or set explorer.autoExpandOptions to []

@Rizhiy
Copy link
Author

Rizhiy commented Oct 8, 2022

No, it freezes when I open explorer.

@weirongxu
Copy link
Owner

weirongxu commented Oct 9, 2022

I made a quick script which should reproduce the problem:

mkdir explorer-test
cd explorer-test
mkdir -p dir1/dir2/dir3/dir4
for idx in {1..100000}; do
    touch dir1/dir2/dir3/dir4/"$idx".txt
done
touch tmp.txt
vim tmp.txt

As mentioned in #535, vim freezes on first open. But if you close (^C) it and open vim again, it works normally but explorer takes a long time to open.

I tried this shell script, but couldn't reproduce your problem. explorer needs to wait until coc.nvim is loaded before it can be opened, It is possible that coc.nvm or coc's extension is scanning the file tree, so coc is loading too slowly.

@Rizhiy
Copy link
Author

Rizhiy commented Oct 10, 2022

I have updated all of my plugins and the problem fixed itself. Must have been something else.

@Rizhiy Rizhiy closed this as completed Oct 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants