Go to line brings brackets to a stand-still.

[krazyjakee]

Using sprint 27 on windows 8.

I'm working with files on a mapped network drive over a local area network.
Brackets handles everything smoothly except for large files (fair enough) and the "go to line" search feature.

The moment I hit ctrl+g brackets seizes up even when the input box is empty. After I click around to get the input area to lose focus, brackets is still very slow for 3 or 4 seconds and then completely back to normal.

It's strange because ctrl+f search is totally smooth.

Thanks.

[peterflynn]

@krazyjakee That's very unusual behavior... Does this happen on all files, or only large ones? Does it happen on local files too, or only files stored on a mapped network drive?

Here's one way you could gather additional info on the issue:

1. In Brackets, get set up to reproduce the bug (have the right file open, etc.)
2. Click Debug > Show Developer Tools
3. Switch to the Timeline panel
4. Hit the "record" button (black dot) in the footer bar
5. In Brackets, reproduce the bug all the way until the freeze is over
6. Toggle the "record" button off again

Now, either (a) take a screenshot of the overall output, or better yet (b) right-click in the timeline and choose Save Timeline Data, then share it with us (use Dropbox or something -- it's way too big to just paste in here).

[krazyjakee]

Typically, today it is behaving better but it is still noticeably slower then a text search.

Download timeline data https://www.dropbox.com/s/kaups9hkl3136oi/b9ad7721-f3ac-4fb4-97e5-ed0a7e12e513%23TimelineRawData-20130716T092548.json

Presumably that function is not behaving itself or is doing more than it should be?

EDIT: forgot to answer your other question.
On local large files it functions pretty much the same speed, but randomly comes to a standstill. I think perhaps the issue is unrelated to go-to-line. I will try to snap some more data.

EDIT 2: Major lag while editing local files on my SSD.

https://www.dropbox.com/s/x2c13gnq6y7o20r/edd62ad9-8d21-4a2d-b672-2a16db70f0db%23TimelineRawData-20130716T094352.json

[pthiess]

@peterflynn - Please try to get more information from @krazyjakee - Thanks much!

[pthiess]

Nominated for sprint 29

[krazyjakee]

If the above information is not enough then I'm kinda stuck. Making an educated guess I would say it's a combination of network performance and IO on my end.

If someone else finds lag maybe it would be worth opening a new issue where we can try to pin it down in general rather then blaming go-to-line.

Thoughts?

[krazyjakee]

It's been happening a lot over the last couple of todays and today I caught a big one.

I ctrl+G and start typing and boom.
The UI quickly slows to being completely unresponsive.
It repeats the same memory actions for over a minute.

https://www.dropbox.com/s/x94sw6rdbpdct3a/cde306a3-5974-4bc1-95d3-538f9c5a8515%23TimelineRawData-20130725T110054.json

Everything returns to normal where the painting events happen about 1.6min

[JeffryBooher]

@krazyjakee can you download and install Process Explorer from Microsoft (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) and keep an eye on Physical Memory Usage and let us know what your memory usage is when Brackets starts to slow. I run Process Explorer with the Physical Memory Tray Icon (Options > Tray Icons > Physical Memory History) so I can tell when I'm starting to run low on memory. When you start running out of physical memory, Windows will move memory to disk and that slows things down as it pages blocks of memory to and from disk.

When physical memory gets close to 85% I start shutting down processes by looking at the ones with the highest working set value in process explorer. If you have a lot of pages open in Chrome then this is a good place to kill those that are chewing up a lot of memory. Just right click on the process and select "Kill Process" or "Kill Process Tree". Chrome processes will disappear but their respective tab will live on so you can reload them later. I wouldn't kill processes randomly without making sure you've saved first. It's always best to shut apps down using the normal method.

At any rate, let us know what you see when Brackets starts to slow. How much physical memory is in use and how much you have total. Thanks!

[krazyjakee]

Snapped this mid-lag. At this point brackets was unresponsive, other software was fine.

While brackets was fine, physical usage was 2.8gb of 4gb. During the lag the usage was the same.
The CPU usage for brackets would peak at about 15% but only very briefly.

I am easily able to recreate this lag with go-to-line. text search doesn't cause this freezing.

I would say that these stats show that it's not a hardware issue. Maybe some kind of conflict?... but then the cpu isn't going crazy.

[peterflynn]

Hmm, these Timeline traces are all over the map.

• The first one shows a slowdown of ~150 ms while opening the Quick Open bar, and seemingly normal performance otherwise -- doesn't seem too extreme. During the 150 ms pause, much of the time is idle on the timeline (suggesting GPU bound or CPU busy with things that aren't instrumented, which could mean certain V8 internals or it could mean the Tern worker thread... or CPU contention with some other process, including our own browser process).
• The second trace shows a dramatic 20-second freeze while closing Quick Open's ModalBar (so presumably after hitting Enter). Every layout takes over a second, for no explicable reason. There's no idle time or other activity going on.
• The latest one shows a persistent slowdown lasting over a minute, with each frame freezing for 3-30 sec. There's a continuous churn of callbacks coming back from the brackets-shell native code -- seemingly triggered by NativeFileSystem.DirectoryReader.readEntries() (its isNetworkDrive(), stat(), and readdir() calls). Each call is very quick but they are stacked up continuously. The CM timer seems to preempt them and run pretty frequently, but nonetheless Brackets is clearly quite bogged down. At times we see a huge batches of readEntries() calls timing out (the callback in Async.withTimeout()), but then the readEntries() calls continue unabated again.

And actually looking back, the very first trace also shows a continuous churn of similar disk IO calls, but for whatever reason Brackets seems to remain more responsive in that instance. The middle trace, however, contains no evidence of that whatsoever.

[peterflynn]

@krazyjakee Here are a few things to try out:

1. How big is the folder structure for your project? Open your project's root folder in Windows Explorer, right-click in a blank area and choose Properties. What does it say next to "Contains:"?
2. Does your project's folder structure have any unusual characteristics, for example use of symlinks / "junction points"... or the folder tree being split between local disk and a network share?
3. Do you have many network shares mapped to local disk letters on your system? How often are any of those network shares either (a) disconnected, or (b) running slow?
4. Go to the Brackets console and run this require("project/FileIndexManager").getFileInfoList("all").done(function (list) { console.log(list.length); }). What number does it print? (If you don't see a number, wait a minute or so).
5. Launch Brackets and let it just sit idle for 5 minutes while remaining the foreground app (so you'll have to go get coffee or something). Come back, and without switching to any other apps try using Brackets. Is it fast and responsive? If so, switch to another app briefly and come back. Does Brackets become very slow then?
6. Are you working with files that have any extremely long lines? (E.g. files that contain some minified content). Do you have word wrap enabled?
7. We probably should have asked this earlier, but can you try disabling all extensions you have installed? Here's one quick way: Help > Show Extensions Folder, rename the "user" folder to something else, quit and restart Brackets. Does the problem still occur?

[dangoor]

We're at the end of sprint 29, so I need to reset the milestone to sprint 30.

[peterflynn]

Moving out of Sprint 30

[peterflynn]

@krazyjakee Are you still seeing this problem? Have you had time to try any of the suggestions I listed above?

[dangoor]

Closing because we don't have any more information to go on. Please reopen for a file a new bug if there is more information available.