Go to Line is extremely slow when project contains many files

[0b10011]

Steps to reproduce

1. Open a project with enough files to trigger the "Error Indexing Files" warning
2. Open any text file
3. Open Go to Line dialog: Navigate > Go to Line
4. Type "90" and press Enter

Expected results

"9" and "0" characters should appear as soon as they are typed and the editor should scroll to line 90.

Actual results

Brackets becomes unresponsive momentarily and after the delay, "9" and "0" appear in the dialog and the editor is scrolled to line 90.

System info

• Brackets 37
• Ubuntu 13.10
• 32 bit (and I'm fairly confident this applies to my 64-bit system at home as well)

[0b10011]

I would be fine with a way to exclude folders for a specific project. For example, in the project that is causing this issue for me, there is a files directory with hundreds of subdirectories that contain thousands of uploaded files that I don't need to access from Brackets (they are ignored with .gitignore and only used by loading files from the database---PHP project).

[0b10011]

It looks like the lag is caused by the loading of the Go to Line dialog, and not typing of the numbers/navigating to the line. If I wait several seconds before typing "90", it works as expected. This appears to affect "Quick Open" and "Quick Find Definition" as well.

[njx]

That's odd. It could be that we kick off a normal find-file Quick Open before processing the fact that this is actually a Go To Line, and that causes a big pause.

[njx]

Actually, @RaymondLim pointed out that it might just be that JS code hints is still indexing files in the background (which seems to slow everything down a bit) since you just opened the project. Does the symptom still occur if you wait a minute or so after opening the project?

[0b10011]

Does the symptom still occur if you wait a minute or so after opening the project?

Yes, it does.

Actually, @RaymondLim pointed out that it might just be that JS code hints is still indexing files in the background (which seems to slow everything down a bit) since you just opened the project.\

The indexing actually causes Brackets to become unresponsive temporarily as well, so I'm not able to even do anything before the "Error Indexing Files" warning pops up.

[peterflynn]

We do kick off a getAllFiles() call when the QuickOpen bar is first opened, but if you've already waited for the code hints stuff to unpause then that list will have already been built and it shouldn't cause a long pause.

It looks like we also treat a bare ":" as a generic Quick Open search though (see #6646), so it's possible the pause is from us doing a StringMatch search across all 30,000 files... @bfrohs If you press Ctrl+Shift+O (instead of Ctrl+G) and then type a single letter char, does it pause for a similar length of time? Does the pause occur before or after typing the letter, or does it pause both before and after?

[0b10011]

Yes, as mentioned in one of my earlier comments:

This appears to affect "Quick Open" and "Quick Find Definition" as well.

However... I don't seem to be able to reproduce this on my machine at home. Feel free to hold off on any more research into this until I can test on my work machine again on Monday... maybe I forgot to reload with extensions turned off? I'm fairly confident I did, though, and I think I have all of the same extensions loaded, so it may just be the speed difference between my machines (new 64-bit i7 with multithreading at home, 4 year old 32-bit i3 at work), but I don't want to waste anyone's time in case it is just an extension issue. I'll check first thing Monday.

[peterflynn]

Specifically though, are you able to find out the answer to this question above?

If you press Ctrl+Shift+O (instead of Ctrl+G) and then type a single letter char ... Does the pause occur before or after typing the letter, or does it pause both before and after?

[0b10011]

Oops, missed that second question somehow, sorry about that. Can't test right now, and can't remember off the top of my head, but I'll let you know first thing Monday! :-)

[peterflynn]

Ok, thanks!

[0b10011]

It can be reproduced with addons disabled.

Does the pause occur before or after typing the letter, or does it pause both before and after?

The pause only occurs before typing the first letter. But it's not typing the character that causes the slowdown... If I wait several seconds before typing a character, it appears immediately. So, it appears to be the initialization of the field itself.

In case it helps, it appears a considerable amount of time (~40% of profile time for Ctrl+G > typing line number) is being spent in:

• (~20%) DragWindow > appshell.fs.stat > stat > anon function > anon function
• (~22%) DragWindow > readdir > Directory.getContents > FileSystemEntry._visitHelper > anon function > anon function

---

It may also be worth noting the machine I couldn't reproduce this on uses a fast SSD whereas the machine I could reproduce this on uses a slow HDD.

[pthiess]

@peterflynn - made this a medium priority to investigate

[slpixe]

Just to add to this,
I've been encountering this in large and small projects for a few months now.

Using OSX, Brackets 41

It appears to cause the lag just by pressing cmd+L, and remains being slow for around the next 10 seconds.

Theres a chance its related when having cssLint open/closed