Atom freezes, disabling elmjutsu seems to solve it

[smucode]

Some time in the last month or two I've had huge problems with atom freezing. When i look at activity monitor, atom helper is using all the CPU. If i try to disable elmjutsu the problem seems to go away.

I tried looking in the dev console, and last time atom froze this is the last few messages:

[elmjutsu] getActiveRecordVariable null 0.12500000093132257 ms
helper.js? [sm]:944 [elmjutsu] sendActiveFile 1.5700000002980232 ms
helper.js? [sm]:944 [elmjutsu] getActiveTopLevel adminServiceGetCrashesForAgent 2.1499999994412065 ms
helper.js? [sm]:944 [elmjutsu] getActiveRecordVariable null 0.11000000033527613 ms
helper.js? [sm]:944 [elmjutsu] getActiveTopLevel null 0.7949999999254942 ms
helper.js? [sm]:944 [elmjutsu] getActiveRecordVariable null 0.1600000001490116 ms
helper.js? [sm]:944 [elmjutsu] getToken module 1 ms
helper.js? [sm]:944 [elmjutsu] sendActiveFile 5.41499999910593 ms
helper.js? [sm]:944 [elmjutsu] Running /Users/smu/.nvm/versions/node/v10.15.0/bin/elm make --report=json --output=/dev/null /Users/smu/src/main/frontend/packages/elm/src/elm/Pages/Atlas/Views/TermInput.elm...
helper.js? [sm]:944 [elmjutsu] sendFileContentsChanged 6.400000000372529 ms
helper.js? [sm]:944 [elmjutsu] getActiveTopLevel renderDatalist 0.9799999995157123 ms
helper.js? [sm]:944 [elmjutsu] getActiveRecordVariable null 0.6650000000372529 ms
helper.js? [sm]:944 [elmjutsu] getToken null 1.6450000004842877 ms
helper.js? [sm]:944 [elmjutsu] sendActiveToken 10.43500000052154 ms

I haven't fiddled too much with the elmjutsu settings, tried to disable datatips but no luck.

I'm using atom 1.34.0, elm 19, node 10, osx 10.14.2. I reinstalled OSX the other day, and even with a fresh install of atom, node, elm and co, the problem occurs.

Heaploads of files in the project, 700k loc js, 95k loc elm. But i've ignored most of that (node_modules, elm-stuff etc), so what should be indexed is around 70k loc elm across 350 files and really no js.

Let me know if there is anything i can do to help debug this...

Love elmjutsu btw, main reason i stick to atom!

[halohalospecial]

Hi, do you have other Atom packages installed? You can try disabling all Elmjutsu features, then enable them one by one to identify which feature is causing the freeze.

[smucode]

Yes. atom-ide-ui, elm-format, elm-lens, highlight-selected, language-elm and last-cursor-position.

I'll try to disable the settings and see if i can narrow it down.

[halohalospecial]

What did you mean by "atom helper"? You can also try disabling elm-lens.

[smucode]

Sure, I'll try disabling elm-lens. On OSX atom spins up one main process Atom and a bunch of extra processes called Atom Helper which I guess is where all the actual work happens.

[smucode]

Still happens with elm-lens disabled. Also disabled all settings apart from hyperclick, same problem. I'm wondering if it's perhaps elm make that's making atom freeze?

[smucode]

Uninstalled atom-ide-ui and wanted to try out getting error messages via linter and linter-ui-default. Both are installed, but no errors are shown for some reason. Is there additional configuration i need to perform?

[ymtszw]

Regarding to linter problem, it may be this: #153
In short, lock linter version with apm install [email protected] for the mean time.

Apart from that, have you tried compiling the project outside of Atom?
If packages already downloaded and initial compilation artifacts in place, subsequent incremental compile should be usually smooth.

[smucode]

Thanks, linter 2.2.0 works. Yes, it's usually incremental updates. Works fine when i start fresh. But then after a while grinds to a halt. Is there a easy way to debug what the atom processes are stuck doing?

[ymtszw]

Dunno, I also want to know convenient ways to debug background processes from Atom packages...

Also, just a possibility though, triggering too much Lint requests to elmjutsu (thusly to the elm compiler) sometimes unstabilize Atom, leading to input lags or "Max call-stack size reached" error shown.

• If you are running elm make "on save", do not trigger them too much
• "Always compile main" is obviously heavier even though the elm compiler is now significantly fast and efficient. Use per-file compilation and occasionally make your whole project outside of Atom, may leads to better experience overall
• Personally, I'm turning off "Lint on open", "Lint preview tabs" options in Linter. Atom is busy on startup so lessening its burden

[halohalospecial]

@smucode, can you also check if disabling the elm-format Atom package makes it better? I sometimes experience slow downs when saving Elm files.

[smucode]

It seems to be related to many files changing. Like when i check out a different branch, or delete elm-stuff due to corrupt files after compile. But i have ignored elm-stuff from indexing, so not sure what would care if that folder changed?

[halohalospecial]

@smucode, you can try ignoring elm-stuff here:

atom-elmjutsu/lib/core.js

Lines 398 to 404 in 196750d

	ignored: [
	helper.dummyModule() + '.elm',
	'repl-temp-000.elm',
	'elm-stuff/packages/**',
	'elm-stuff/build-artifacts/**',
	'node_modules/**/*',
	],

[smucode]

Sure, i'm using a fork now. I'l try some different things and report back if i get any wiser!

[smucode]

I notice whenever a hyperclick opens the elm docs, there seems to be a process lingering. When i looked the other day I had 20-30 of these:

$ ps aux | grep elm
smu              86782   0.0  0.1  4334260   9828   ??  S    11:45PM   0:00.06 open -W http://package.elm-lang.org/packages/mdgriffith/elm-ui/1.1.0/Element
smu              86781   0.0  0.1  4334260   9832   ??  S    11:45PM   0:00.06 open -W http://package.elm-lang.org/packages/mdgriffith/elm-ui/1.1.0/Element#Element

They don't go away when i close the browser tab.

[smucode]

Haven't had too much time to dig any deeper, but I did change the ignored patterns to ignore all of elm-stuff and node_modules and I haven't experienced atom freezing since. I'm not sure it's this change that helped.

After the freezing stopped, i am noticing atom just being a lot slower lately. After a while switching tabs, hyperclicking etc seem to take a long time (+1 sec). My colleague also is having similar issues.

Not sure if it's possibly related to this one #115 you fixed a while back? The symptoms are quite similar at least.

[smucode]

Just to demonstrate the problem, I'm here holding CMD and I'd assume the hyperclick underlining should tigger a lot faster.

[icidasset]

Hey folks, wanted to note that I'm experiencing this issue, aka. a freeze, as well. For me it's because I have a git submodule which is an Elm project as well, and if I build this "sub project" Atom often freezes.

So I guess this is related to the file watcher, as you suggested @halohalospecial.
I assume the current ignored setting only ignores the elm-stuff at the root of the projectDirectory, not the nested ones?