core-ai-bot
commented
3 years ago 
@haabe Start by using Debug > Reload Without Extensions to see if this is being caused by an extension. If not, then we'll need you OS/version and version of Brackets.
Open core-ai-bot opened 3 years ago
core-ai-bot
commented
3 years ago
@haabe Start by using Debug > Reload Without Extensions to see if this is being caused by an extension. If not, then we'll need you OS/version and version of Brackets.
core-ai-bot
commented
3 years ago 
Also: how large is the file you're seeing this in? Is it a minified file? If you open the default 'Getting Started' project that comes with Brackets, does the problem occur for the files in that project too? And lastly -- does regular Quick Open (Ctrl-Shift-O) work correctly for you?
core-ai-bot
commented
3 years ago 
@redmunds There's no difference if I start it without any extensions.
@peterflynn It happens in many different files, the latest I tried was a small CSS file (6kb, 231 lines long). It is not minified.
I have no trouble with the files in the Getting started folder.
Quick Open also works with the Getting started folder, but if I try to open one of my projects, Brackets die (or enters some kind of coma).
I am running Windows 7 SP1 and Brackets 0.44.0-14876 (release 6d2d33d80). The projects I work on are located on different servers on the LAN, so there are no local files.
The CSS file I mentioned is placed on a local Linux server, where the html root folder is mapped to my X: drive in Windows. It is part of a Wordpress theme, so the path to the project file in Brackets is X: > wp-content > themes > themename > style.css.
If I choose the themename folder as the project root folder, I can use Go to line and Quick Open without any problems.
So maybe the issue is if there's too many folders in the project, or the file is to deep in the project or something?
core-ai-bot
commented
3 years ago 
I'm also seeing this issue as well. Sometimes the whole application hangs for a good 10 or so seconds, and continues to be laggy (but unlocked) for about another 10 seconds after that. The top UI (file, edit etc) still work, but clicking on options within each menu doesn't work.
Scenario:
Open up any file. Press Control-G. Prompt loads to input line number. Input a number. The program hangs and takes a long time to load the line in question. I tried this with both extensions loaded and without, the latter ran a bit quicker but not by much.
I do have a large project open, and it's on a networked drive. However, other programs such as SubLime Text haven't had such issues with Go To line before.
Tried this on two files, one 270 lines long and one 544 lines long, not exactly anything excessive.
Oddly enough doesn't lag so much on Open File, just Go To Line.
Specs: Windows 7, Release 0.44 experimental build 0.44.0-14876 (release 6d2d33d80)
core-ai-bot
commented
3 years ago 
@Maelstrome26@haabe can you install Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) and let us know 1) what the memory usage is of all Brackets processes when this happens and 2) how much Physical Memory is available to the system when it does. The "Slow" part generally indicates that Brackets CEF process is spending a lot of time in garbage collection which can make things go really slow.
You can get the available physical memory (View > System Information) then click on the Memory Tab.
core-ai-bot
commented
3 years ago 
@Maelstrome26 We would likely raise this to a high priority if we had information to reproduce -- thank you :)
core-ai-bot
commented
3 years ago 
@pthiess I got a recipe:
Ctrl+G to invoke Go to LineThis issue is probably a dupe of #7395, except that here we are using a network drive. And it's somehow also related to #6646.
core-ai-bot
commented
3 years ago
@MarcelGerber Thanks for the steps- seems a bit like a corner case - adding a Needs review to discuss.
core-ai-bot
commented
3 years ago
I think I have discovered the culprit.
When looking into the memory use using Process Explorer, I let the non-functional Brackets window be while taking screenshots and taking notes. After a (long) while, Brackets showed this error message.
After I accepted the message, Go to line worked flawlessly.
core-ai-bot
commented
3 years ago 
Closing as we have a variety of things in mind for large projects. Thanks for the additional detail.
core-ai-bot
commented
3 years ago 
@dangoor, you keep closing this this issue even if it's been out there for more than one year now, but, no matter the release, there's no improvement. I saw quite some interesting closing reasons by now, but this one - "we have a variety of things in mind for large projects" - it's by far the most disturbing one; ffs, this is about usability; i'm working now on a project with ~13500 files in ~1600 folders and the lag is killing me, i spend more time waiting for brackets to respond then i spend actually working on the code. And since Adobe killed the Edge Code, there's no one else to talk to. Come on!...
core-ai-bot
commented
3 years ago
@robertvasile I hear you. We know that there are issues with larger projects and we don't need 100 slightly different open issues in GitHub to tell us that. It's a matter of prioritizing all of the many things that could potentially be worked on. We've done some things that help with larger projects, such as the Find in Files filters, but there's more to be done. Probably the lowest hanging fruit is the ability to reduce the scope that Brackets works in to a smaller set.
While there are certainly many Brackets users that have largish numbers of files, there are also many than do not and it's a balancing act between improving support for larger projects and adding features for smaller ones.
cc@ryanstewart
core-ai-bot
commented
3 years ago
@dangoor I hear you too; business-wise, i even understand why this issue has a lower priority in your schedule.
still...
keep in mind that i'm reading your blogs ever since early 2ks and i respect your contributions to the community, so there's no biased intention behind my posts regarding this issue; a little frustration... maybe
also keep in mind that you're talking to a full subscriber of Adobe CS and so my expectations are high; i've been a devoted and exclusive user of edgecode/brackets, yet, in a very diplomatic manner, you're telling me to use something else for larger or oversized projects...
if the dev team needs more resources/coders, ask for help, start a donation based subscription, start a kickstart, do something to resolve that issue, but please stop this prioritization bs... this issue reffers to a basic function of an editor, a faulty implementation by design, in this case, not to some insane nice-to-have feature...
striping your answer of it's diplomacy, all i have to do is to consider some goddam good days wasted, days i spent tunning brackets and it's extentions to look/work the way i like/want/need them to... and i'll go back to sublime text
me and probably others like me...
i dont wanna do that. do you?
core-ai-bot
commented
3 years ago
heh... or replace the statement on brackets.io with:
"A modern, open source text editor that understands web design for small projects."
core-ai-bot
commented
3 years ago
@robertvasile Is this a duplicate of #7395 (which is still open) ?
This is an open source project, so any contributions to help us solve this problem including information to help us isolate issue, code suggestions, or pull requests are greatly appreciated.
There is going to be a lag when file is first opened and loaded from disk. You should double-click on file to load it in working set so it's not reloaded every time you switch to it.
There will be another lag for the first time you cause all project files to be indexed (e.g. using Quick Open, Find in Files, etc.). These lags will be longer on a network drive.
Have you tried using the Exclude Folders extension to minimize the number of files that Brackets loads?
Do you still see problem after those initial lags?
Have you tried disabling linting using View > Lint Files on Save ?
Have you tried disabling JS code Hints using codehint.JSHints preference? (See https://github.com/adobe/brackets/wiki/How-to-Use-Brackets#preferences for more info on preferences).
core-ai-bot
commented
3 years ago
@redmunds
[edit] it is idd a duplicate #7395, as it refers to brackets' go to line usage within projects containing a large amount of files and rather complex file trees.
i'm not talking about opening or previewing files, indexing project files, linting or any of the cases you enumerated above.
i refering to the plain and simple go to line: a. just clean install brackets, b. open a project folder containing a large amount of files and rather complex file trees (my personal estimation is around >700 files and >100 folders and subfolders) c. open a file (any file), loading it in in working set d. use go to line
you will get a lag spanning from 3-5s to 20-30s, i suspect depending on the size and compexity of the file tree
core-ai-bot
commented
3 years ago
@robertvasile
i'm not talking about opening or previewing files, indexing project files, linting or any of the cases you enumerated above.
Yes, I understand. But those other features (which are enabled by default) open processes in the background that can slow down what you are doing in the foreground.
core-ai-bot
commented
3 years ago
@redmunds
not when you're running a quad core / 8 nucs i7 with 24GB ram :)
core-ai-bot
commented
3 years ago
@robertvasile That's not necessarily true with JavaScript. JS has a separate rendering thread, but everything else is single-threaded. The exception to this is web workers, but JS Code Hints is the only feature mentioned that uses web workers.
core-ai-bot
commented
3 years ago
@redmunds I agree with@robertvasile, the "Go to line" feature, even though I don't use it that often, is one where there's definitely no need to index the project.
core-ai-bot
commented
3 years ago
@MarcelGerber I totally agree with that. I am not sure if that's what's going on here, but it should be an easy problem to fix.
core-ai-bot
commented
3 years ago
It's probably the deep connection with the QuickOpen code (well, they use the same input). One possible solution would be to only fetch all files if the first typed char is not : or @.
You can clearly see the underlying problem looking at #6646.
But eventually, we should find a better way to handle network drives, as fetching just about every file with content from them is very heavy.
[CTRL] + g opens the go to line field as expected, but when I type in a line number, Brackets slows down almost to a complete halt until it won't respond to much of anything in the end. Only way to stop the behaviour, is to force close Brackets.