autocomplete-lua slowing down/crashing atom

[Nexela]

I have narrowed down an extreme perfomance / memory leak to autocomplete-lua. This just showed up recently in atom.

With the autocomplete-lua package enabled and my project opened Atom starts slowing down and I can watch atoms memory usage climb past 2gigs until it finally becomes unresponsive and crashes.

The same happens with previous 3 versions of autocomplete-lua so possibly a change in Atom that caused this?

[dapetcu21]

Thanks for the report. I'll take a look. Can you provide a bit more context? What are you using autocomplete-lua for?

[Nexela]

I use it mostly for the completions from require'd modules. Using the latest Atom (or Atom Beta) and a fresh .atom folder with just this extension the slowdown showed up.

Using this repository https://github.com/Nexela/PickerExtended/tree/3.0.0 editing control.lua the problem shows up just start typing away and you will notice it getting slower and slower and memory usage climbing.

[dapetcu21]

Thanks for the details. I'll try to reproduce. I should be able to look into this and other maintenance issue for this package this weekend

[dapetcu21]

By the way, in your project you can just replace the full absolute path in your .luacompleterc with just { "cwd": "." }

[dapetcu21]

I can definitely reproduce the leak (almost to the point the heap profiler crashing) and I've been trying to debug it for the past two hours with no success. The codebase as it is now is pretty messy (mostly due to storing types in custom, mutable data structures which are hard to debug). I've been mulling these past weeks on the idea of a full rewrite using proper control flow analysis theory. That might take a while, though. Meanwhile, I'll add a config option to just autocomplete the current file (ignoring require()-d modules) in the next release. That should, at least, mitigate the issue.

[AGulev]

Yea, i have the same issues when the project gets bigger