[Feedback] Experimental Fast Mode

[jasonrudolph]

New in fuzzy-finder v1.13.0: Experimental fast mode

New in v1.13.0, fuzzy finder offers to enable a new experimental fast mode when a large project is detected. Fast mode offers dramatic speed improvements:

• Indexing is 5x to 14x faster for large projects (Add option to use ripgrep for crawling the list of files #369)
• Filtering is 17x to 22x faster depending on project size (Use fuzzy-native as an alternate scoring system #374)

We think you're going to love these improvements.

How do I try it out?

These improvements are available in Atom 1.37, which is currently available in beta. When fuzzy finder detects a project with more than 10,000 files, it offers to enable experimental fast mode.

Having problems with experimental fast mode?

If you try out the new experimental fast mode and encounter any problems with it, please leave a comment below to let us know.

[visheshvvs]

Tried the experimental mode for my Django project. Rather than having my custom made python file in the search suggestions, it pointed me to Django's internal project files. Somehow it gives them priority over my custom file? Love the concept, but didn't work for me.

[rafeca]

Thanks for posting @visheshvvs ! We want to make the fast mode work for everybody, so this feedback is really appreciated.

Can you give me a bit more information about the text that you used for the search, some of the paths that appeared first and the paths that you expected to appear?

Even a couple of screenshots showing the fuzzy finder and its results with the fast mode enabled and disabled will do the trick 😃

Note: As a workaround, if you don't want any django file to appear in the fuzzy finder you can ignore the django folder from the fuzzy finder package settings:

[visheshvvs]

@rafeca Thanks for that tip, added lib as an excluded directory and I'm no longer seeing those files.
Just FYI, here's the search results with the experimental mode on without the excluded directory.

[aviatesk]

Thanks for this improvement !

Though with my Atom v1.38.1 x64 on Windows 10, the fast mode of fuzzy finder does NOT seem to ignore VCS-ignored files even though I have the config setting to ignore them.

If I switch back to the previous mode (alternate), then they get ignored again so I suspect this is caused on fuzzy-finder side (actually it needs reloading Atom, thus it seems that this behaviour is caused at package-loading time).

Is this behaviour intentional ??

[rsese]

Hmm, I'm unable to reproduce on Windows 10 with 1.38.1 @aviatesk. Can you share a minimal example where you see this behavior?

I tested with a test repo with this .gitignore:

test.txt

And 2 files, test.txt and test2.txt. With fast mode enabled, when I open fuzzy finder I see test2.txt and I don't see text.txt as expected.

Do you see the same behavior with this example ☝️?

[aviatesk]

@rsese
Thanks for trying to reproduce my issue !

I missed to clarify what I meant by VCS ignored. I confirmed .gitignored ones are surely ignored, but atst noticed the fast mode shows some files in .git directory like config and COMMIT_EDITMSG while alternate mode doesn't show those files.

I'm not sure about this is an intentional behaviour, but both modes are better to show the same files as possible for consistency.

P.S. I confirmed some files in .git like files in .git/objects/ are still not shown in fast mode.

[rafeca]

@aviatesk tanks for the additional info! I've been able to reproduce your problem by removing the .git entry from the "Ignore names" core setting:

(by default, this setting has the .git folder as the list of ignored folders)

I've done some research and:

1. This happens only with the .git folder: other VCS-ignored folders are correctly ignored in the fast mode, no matter the "Ignore names" settings.
2. This is in fact a change of behaviour of the fast mode: previously, the .git folder was ignored when the "Exclude VCS ignore paths" was turned on, so having that folder on the "Ignore names" setting was not needed (even if it was added by default there).
3. This seems to be caused by ripgrep: I could reproduce this issue by executing the rg binary directly (by running rg --files --hidden).

To work around this issue, we could manually add the .git folder as the list of ignored globs to this logic:

if (this.ignoreVcsIgnores) {
  args.push('-g', '!.git')
  args.push('-g', '!.hg')
}

@aviatesk do you want to send a PR to fix this?

[aviatesk]

@rafeca

Thanks so much for investigating this issue and even proposing the workaround idea !
Yes, I tweaked "Ignored Names" settings as you found.

do you want to send a PR to fix this?

I really want to ! (I will just follow your ideas tho.)
Personally I've always wanted to contribute Atom's core and its packages, thus I really appreciate for you giving me the opportunity 😁

[Songworks]

I've tested it a bit. I'm impressed by the speed, so kudos!
However it doesn't seem to find the same results as the alternate scoring system.

For example with the alternate system and fuzzy-finder:toggle-file-finder I could enter a PHP Classname fe. Magento\Catalog\Model\Product\Image and it could find me the correct file ([...]/magento/module-catalog/Model/Product/Image.php) based on those searched words, irrelevant of the separators / or \.
This doesn't work with the fast scoring system. It doesn't with the standard system also, so I suppose it is as expected?
But since the alternate one appears to be the default setting, I just thought I'd mention it though.

Cheers!

[rafeca]

Thanks for the feedback @Songworks, this is a good catch!

I've just did some testing and you're right: on OSX/Linux you can search for folder/file.txt but not for folder\file.txt (interestingly, both searches work correctly on Windows 🙃).

It seems like the alternate mode was more permissive with the slash and backslash characters (e.g with alternate if you search for Dock/er/file it also matches a file called Dockerfile.

I think that the current behaviour is more correct, and the fact that PHP classnames worked on the previous implementation was just coincidental. Still, I don't have a strong opinion on that, so I wouldn't be opposed to a PR that makes things like Magento\Catalog\Model\Product\Image match the magento/module-catalog/Model/Product/Image.php file (as long as it does not break other things).

[GarethWelch]

This mode is extremely fast in comparison to the current system. An issue I've come across is that files don't seem to be indexed when they're added by checking out a git branch. I'm finding it hard to keep using this mode with said issue.

[rafeca]

@GarethWelch this is not an expected behaviour, can you provide more details about the issue? which platform are you using? how do you checkout branches? via command line? the standard mode and the fast mode should use the same watching behaviour so I'm wondering what could make you experience this issue...