Sublime Forum

Goto Anything... is very slow

#1

Hi all,

My “Goto Anything…” used to be blazing fast, but all of a sudden it changed (a few months ago already…). It was perfect for a long time and then all of a sudden the next day it was slow as hell.

Video: screenr.com/rT8H
(typing louder so you can see how long it takes compared to me typing).

And this is still “fast” considering how slow it gets during the day now.

I tried reinstalling and using it without plugins, but it’s still slow. I tried using ST3 with no plugins, also no luck…
Also coworkers with the same project don’t have this issue, so I don’t think it’s project size related… And as it worked fine for months that also proves it really.

Anyone else have this issue? Is it known? Can I help debug?

My machine is an iMac 2.9 GHz i5, 8GB memory.

Regards.

1 Like

#2

Have you tried restarting your Mac? I know this is a common tip for Windows, but I have seen it work with my Mac as well. :smile:

0 Likes

#3

I am actually having the same problem, although it started for me just last week. Unsure what could have changed between when it was working quickly and when it started running slowly, and suggestions on determining a cause or a fix would be appreciated.

The moment I noticed it start for me, I figured that maybe there was something going on behind the scenes of my mac and restarted. However, this didn’t seem to help anything, and I’m not really certain what other information I could supply to help troubleshoot the issue.

[EDIT] Also, i should point out that I’m using Sublime Text 2. the original poster said they were using ST3.

0 Likes

#4

I’d like to add another voice to the problem. I’m working within a rather large project (a few hundred files), and the Goto Anything dialogue is very slow. In particular, I have a number of files (around 20) that start with the same phrase, “FakeFactor…”, and after typing in “Fake”, each successive letter I type takes ~1-4 seconds to appear on screen.

I’ll also note that I don’t experience the problem on my Ubuntu desktop, only on my Mac laptop; whether it’s the operating system or the available system resources, I have no idea. Regardless, though, I think at least the rendering of text on-screen needs to be detached from the search process itself, so that the dialogue doesn’t become useless when the search bogs down.

0 Likes

#5

+1 to the same problem, I have removed every plugin on sublime text 3 BUILD 3047, and it’s still performing really slowly.

0 Likes

#6

I’ve been having a similar problem on my Linux machine with ST3 3047, so I decided to attach strace and see what was going on. You can do this yourself by running “sudo strace -p -T <sublime_text_process> -o sublime.trace” and then trying to use goto anything a couple times. That’ll record the time for each system call in seconds and append it in <> to the end of each log line.

In my case it looks like the close() operation on the inotify_add_watch() is taking half a second or more in many cases – and it’s being called nearly every other keystroke.

Here’s the trace output for one of the directories in my project: pastebin.com/kgAh51pP – Note the close() time here:
close(128) = 0 <0.502742>

I’m not sure why close() is taking half a second. The drive is an SSD and the project contains ~140k source files (Chrome). In any case, it’d be nice if SublimeText could defer close() operations to a non-UI thread to avoid this sort of blocking.

0 Likes

#7

Thanks for the investigation Dale. I’ll put a change in the next build to reduce the number of inotify_add_watch()…close() calls during Goto Anything, which will hopefully be enough to address the issue.

0 Likes

#8

Awesome. Thanks for your great work!

I’m following up with some kernel folk on why close() is taking so long. I’ll update here for posterity’s sake if that results in an upstream bug anywhere. The speculation points to the read-copy-update (RCU) mechanism used by inotify and its required grace period. Additionally, the issue appears “fixed” in 3.3+ kernels, though the close() is still not all that fast (~36ms).

$ uname -a
Linux … 3.2.5 … x86_64 GNU/Linux

$ strace -T ./inotify

inotify_init() = 3 <0.000112>
close(3) = 0 <0.529482>

$ uname -a
Linux … 3.3.8 … x86_64 GNU/Linux

$ strace -T ./inotify

inotify_init() = 4 <0.000146>
close(4) = 0 <0.036985>

0 Likes

#9

It seems that uninstalling sublime and reinstalling it back fixes the issue. It leads me to think if it has anything to do with the caches that were stored for every time goto anything opens up the dialog. I didn’t dig further since for now it seems to work good enough for me, but hopefully this information helps.

Looking forward to the next build.

PS. I’m also on Ubuntu 12.04 LTS, and sublime 3047 BUILD.

0 Likes

#10

I’m sorry for not responding anymore, I have been on holiday.

Is there any news on this? Have changes been made? If so I’d like to hear if it worked and if it is ST3 only (seeing as I’m still using ST2).

Thanks!

Edit:
To give some information on comments the rest gave:
Restarting: This doesn’t help, I guess it’s quite obvious when I say I have had the issues for a couple of months now.
Reinstalling: Also didn’t help me, also have the issue on both ST2 and ST3.

0 Likes

#11

I just tried the latest 3052 Dev Build and the performance is infinitely improved; presumably due to the fixes mentioned above. I’m unable to detect any lag using Goto Anything now.

Thanks and great work!

  • dale
0 Likes

#12

I don’t know if this is the same problem, but I’m also experiencing a significant slow down of goto-anything on ST3. I’m on a Windows x64 machine, and I’ve tried it with 3047 and now 3053… both are slow. Is this problem officially resolved?

0 Likes

#13

+1 having the same problem.
It started with one of ST3 builds compared to ST2.
I am using Mac and Windows and on Mac it is defiantly worse… very slow.
Looking forward for fixing this as it is really renders using Goto Everything annoying on my Mac

0 Likes

#14

I am facing the same problem, it was not there with ST2 but after buying the license for ST3 this issue poped up. I tried all suggestions mentioned above but nothing worked out. In Fact going back to ST2 does not help either.

I am facing this issue with latest stable build as well as latest dev build both of ST3.

I am on ubuntu 13.04/64bit.

0 Likes

#15

Goto Anything slowdowns are most frequently caused by plugins doing work when a file is loaded. You can try reverting to a clean state, and seeing if the issue persists: sublimetext.com/docs/3/revert.html. If you’re on Windows, a less intrusive way to test is to download the portable version and see if the problem persists there.

0 Likes

#16

started fresh and it works like a charm, so I am adding now the minimal set of packages one by one.

thanks jon.

0 Likes

#17

FYI - for anyone stumbling upon this thread in the future… for ST3 the following works for me:

edit your user settings.

// folder_exclude_patterns and file_exclude_patterns control which files // are listed in folders on the side bar. These can also be set on a per- // project basis. //"folder_exclude_patterns": [".svn", ".git", ".hg", "CVS"], // commenting out as I want to see these "file_exclude_patterns": [".pyc", ".pyo", ".exe", ".dll", ".obj",".o", ".a", ".lib", ".so", ".dylib", ".ncb", ".sdf", ".suo", ".pdb", ".idb", ".DS_Store", ".class", ".psd", ".db"], // These files will still show up in the side bar, but won't be included in // Goto Anything or Find in Files "binary_file_patterns": [".jpg", ".jpeg", ".png", ".gif", ".ttf", ".tga", ".dds", ".ico", ".eot", ".pdf", ".swf", ".jar", "*.zip", "vendor/**", "node_modules/**", ".certs/**"] // notice the last 3 items 'vendor/**' etc... this is the magic.

2 Likes

#18

Wow, awesome! I made an account here just to thank you for this. Works like a charm.

0 Likes

#19

Yes, this worked for me also. I had thought it was due to node_modules etc, and it was. Thanks.

0 Likes