Mac OSX Performance

[ghost]

Brackets opens up fine, but the instant I start editing a file (of even tiny proportions), the typing, scrolling, and arrow navigation is so slow it's completely unusable. For a while after opening it, things run only relatively slowly (about 100-200 ms delays between key press and text modification), but then it quickly deteriorates. All my other applications run fine, so it doesn't seem to be the memory on my computer.

I recently upgraded to Mavericks, hoping that would be the solution, but no. All releases of Brackets have done the same thing.

[zhouyixiang]

I have the same issue. My system is Mavericks and I use Chrome with Brackets for developing. Brackets becomes slower and slower during development and finally gets no responding. I can see there're bracket helper processes in the Activity Monitor, one consumes 100% CPU and the other is not responding.

[sbruchmann]

This is also reproducible for me on Mac OS 10.7.5.

[njx]

That doesn't sound good. Could each of you respond with a list of extensions you have installed (if any)?

[ghost]

Code folding, delete to line start/end, and live markdown preview. I just uninstalled them all, though, and it's still slow.

Strange, though - for me, Activity Monitor shows Brackets uses only 0.1% of the computer's memory.

[sbruchmann]

I disabled all user extensions, but the problem still exists.

[peterflynn]

Additional questions:

• What version of Brackets are you using? (If you've seen this with multiple versions, please let us know that too)
• Does this occur even when you're editing a plain .txt file? Or only specific file types?
• If you make a new empty folder containing a single plain .txt file, and use File > Open Folder to open just that one folder (so there's only one thing listed in the file tree on the left side), does the problem still occur?

[peterflynn]

Btw @GymbylCoding, how are you estimating the delay when pressing keys? 100 ms is extremely short -- in fact it'd be hard to find any text editor with a delay much less than that -- and it should feel essentially instantaneous to the naked eye. (200 ms on the other hand can feel noticeably laggy).

[ghost]

• Issue is occurring with every version of Brackets I've downloaded since Sprint 29 (which is when I first got Brackets), which would be 29, 30, 31, and 35
• I've tested it with .txt, .js, .css, .html, and .lua and they all have the same problem
• Still have the problem

For a while (or when I have a tiny file open), it'll be quite responsive, sometimes perfect (on the level of TextEdit - not quite that of Sublime, but quite close), but often slipping into more like 200 ms. I've noticed it especially slows down when I navigate by holding down the arrow keys. I've also found (naturally) a connection between any file over about 30 lines and the speed issue. Each new line seems to slow it down incrementally, but after 30 or 40, it gets noticeable. There isn't the same connection (as far as I can tell) with columns - tried ten lines with 470 columns each, and it's perfectly responsive.

[peterflynn]

@GymbylCoding Can you try unchecking View > Highlight Active Line and see if that makes any difference?

[ghost]

With View > Highlight Active Line disabled, Brackets is completely responsive and fast. Thanks so much for help with this issue!

[njx]

I'm wondering if we should take that feature out for now (or highly prioritize figuring out what the heck is going on with it). We've had so many reports of performance problems with it on.

Other folks on this thread - could you verify that the problems you're having are also related to Highlight Active Line? If not, we might want to split out a separate bug.

[njx]

See existing bug #5000. I'll nominate that bug to get looked at soon (and tagged this bug in that bug so we can look at it too).

[TuckerWhitehouse]

Just to add, I too have been experiencing performance issues (and I do not have Highlight Active Line enabled).
Running the latest from git (compiling the shell as well) on OS X Mavericks.
The issue also occurs with user extensions disabled.

[peterflynn]

@TuckerWhitehouse Could you file a new bug so we can investigate that separately, then? If you can, please include answers to the questions I listed in this comment above.

[sbruchmann]

I’m always pulling from the latest master branch of Brackets and brackets-shell. Unfortunately, I don’t remember exactly at which point the bug was introduced, but I think it was in Sprint 29, as @GymbylCoding mentioned.

After disabling Highlight Active Line and all user extensions, removing all projects and creating a blank folder, Brackets became more responsive in plain text files. However, as soon as I edited a JavaScript file with about 50 lines, typing became much slower and laggy. Highlight Active Line definitely slows things down, but the culprit for the initial bug report might be CodeHints.

[njx]

At this point it sounds like the original filer @GymbylCoding's bug has been fixed, so we can close this specific bug. @TuckerWhitehouse has filed a separate bug for his issue.

@sbruchmann, since your issue wasn't fixed by turning off Highlight Active Line, could you look at @TuckerWhitehouse's bug (#6457) and see if it seems similar to yours, and if not, file a new bug describing what you're seeing? If possible, filing the last test case you described (with a small project and a small JS file) would be very helpful. Thanks!

[lkcampbell]

FYI, @TuckerWhitehouse already ruled out Code Hints on his bug. @sbruchmann, you can use the same process I described in issue #6457 to rule in or rule out Code Hints as a culprit. If you find Code Hints are the culprit, that may be a different issue again. If you rule out Code Hints, you might be seeing the same problem.

[IKKYU-san]

Ive noticed pretty much all pages that use alot of javascript or my own javascript games, make the google chrome helper use 100% cpu and overheat my mac. So i dont think the problem is with brackets but instead with chrome.