'w' word motion is abominably slow in 60k line file, because of TextBuffer

[jedwards1211]

Execute Vim Mode Plus: Clip Debug Info(which write info to clipboard) then paste here.

debug info

{
  "atom": "1.34.0",
  "platform": "darwin",
  "release": "18.2.0",
  "vmpVersion": "1.36.0",
  "vmpConfig": {}
}

Read and check all "Checklist" below.

Checklist

You have to check all before open issue.

• Provide your environment info clipped by Vim Mode Plus: Clip Debug Info command.
• Try with latest Atom and latest vim-mode-plus.
• Pick a descriptive and non-ambiguous subject
• Express "what" you want(feature? config option?, behavior change?) in short sentence(not long!).
• Contrast current behavior if you want to change current behavior, with sample text, operation(keystroke) and result.
• Include real use case so that maintainer can understand "why" you need help.
• Include Atom(atom --version), vim-mode-plus version, and OS version(e.g. macOS Sierra 10.12.3).
• If keybinding issue, Read this.

Here is an imitation of the data file I'm working with (60k lines):
sample-cave-data.txt

Moving forward by a word (w command) at the beginning of the file takes approx 240 ms per jump. Near the end of the file it only takes 1 ms per jump (see profiler output below).

240 ms is painfully slow. I'd like w to take 1 ms everywhere within a file of any size.

Slowness comes from TextBuffer.findAllInRangeSync. (TextBuffer also makes search and replace performance utterly pathetic in large files, so I don't blame vim-mode-plus for this really, thanks for all of your hard work!)

Versions

OS: macOS Mojave 10.14.2
Atom : 1.34.0
Electron: 2.0.16
Chrome : 61.0.3163.100
Node : 8.9.3
vim-mode-plus: 1.36.0

Saved profiler output

vim-mode-plus-slow-word-motion.zip

Profiler screenshot -- start of file

Profiler screenshot -- end of file

[t9md]

Thank you for reporting and investigating issue very clearly.
I agree it painfully slow with the file you attached.
But strangely, b(counterpart of w) is not such slow.
So there is the chance I can fix this stressful behavior on vmp side.
I will investigate it next week, will update result.

Thanks.

[t9md]

Why native cmd-f isn't slow is it only scan current row and next row(but vmp scan current row to end-of-buffer).
vmp can opt-in this approach in some motion. but for the motion like move-to-next-smartword(similar to normal w but which skips whitespace only row), I need to scan more lines when cannot find a match.

Limiting search range to the current line and next line approach can be used only when it is acceptable to stop the blank line.

[jedwards1211]

@t9md really the atom folks just need to fix performance problems in TextBuffer, it has serious issues...