'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

```json { "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.

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