Performance issue on files > 150-200 lines about autocomplete-paths HOT 15 CLOSED

+1, had the same issue in CSS-Files

from autocomplete-paths.

👍

Same problem (in a JavaScript file) immediately after upgrading to 1.0.0.

from autocomplete-paths.

Does anyone have an example file that they can share (perhaps via a gist) that doesn't have any sensitive information? I'd like to include that file in the repo and reproduce this with a test.

from autocomplete-paths.

This looks related to #38...

from autocomplete-paths.

Here's a dummy file filled with JSON you can use to reproduce:
https://gist.github.com/doggan/11feabb4d004332f1aab

Start typing at the bottom of the file (i.e. console.log('hello world');) with autocomplete-paths enabled and you will see a noticeable delay. Disable the package and the delay disappears.

from autocomplete-paths.

It doesn't seem to be related to line count - I created a 1000 line file with 1 char on each line, then started typing on line 1001: a = https://github.com/hello. Will try with your file @doggan.

from autocomplete-paths.

Thanks, that file was helpful.

from autocomplete-paths.

This is weird - the size of the file really shouldn't be impacting the time taken to get through this section of code. If anything, the number of files and directories in your current directory should.

This provider should switch to being async in any case.

from autocomplete-paths.

OK, this seems to occur when there is NOT a ./ or / in front of the path on OS X. I.e. just typing "https" at the bottom of that json file reproduces it.

from autocomplete-paths.

Question: should relative paths that aren't prefixed with ./ (on OS X / Linux) or .\ (on Windows) be shown? if not, this is an easy fix.

from autocomplete-paths.

I'd say 'no'.

Seems like it would cause a lot of interference with standard autocomplete.

from autocomplete-paths.

The regex has to change. It's currently: /[a-zA-Z0-9\.\/_-]*\/[a-zA-Z0-9\.\/_-]*/g which isn't the best.

from autocomplete-paths.

The regex is doing a global match and there are no line modifiers. https://github.com/atom/atom/blob/98a874808ea00758d84bb45e0b716498d4916b5b/src/cursor.coffee#L504 dictates the start of the range to search being the last non-blank-row, which in your json = the whole document. That's badness, but not causing the issue. The issue is that the prefix could be the entire document in this scenario, which then causes path.basename / path.dirname to take an eternity.

Thanks for reporting this and figuring it out; it gives me a solid lead to create a test and then fix the issue and prevent future regression.

from autocomplete-paths.

The old code that identified the prefix constrained the search to a single line:

prefixOfSelection: (selection) ->
     selectionRange = selection.getBufferRange()
     lineRange = [[selectionRange.start.row, 0], [selectionRange.end.row, @editor.lineTextForBufferRow(selectionRange.end.row).length]]
     prefix = ""
     @editor.getBuffer().scanInRange @wordRegex, lineRange, ({match, range, stop}) ->
       stop() if range.start.isGreaterThan(selectionRange.end)

from autocomplete-paths.

Thanks for the fix @joefitzgerald! Performance issues seem to be gone. ✨

from autocomplete-paths.