Flesh out the regex search APIs

[maxbrunsfeld]

Problem

While @leroix and I were looking into the performance of the new findWordsWithSubsequence method and its use in autocomplete-plus, we noticed that a huge amount of time was being spent in the Cursor.getCurrentWordBufferRange method.

There are a few reasons why this method is slow:

• It uses the old TextBuffer.scanInRange API rather than a native search API from superstring.
• The scanInRange APIs are especially inefficient when they are passed RegExps that can potentially match across line breaks. Currently, RegExps that contain negated character classes (e.g. [^x] are assumed to be potentially multi-line.
• The word-regex used by getCurrentWordBufferRange uses a negated character class based on the editor.nonWordCharacters config setting.

Solution

We should optimize scanInRange, ideally using superstring's native search functionality.

First step

This PR expands the set of search APIs. The final list of search APIs will be as follows:

• find
• findSync
• findAll
• findAllSync
• findInRange
• findInRangeSync
• findAllInRange
• findAllInRangeSync

Before actually changing TextBuffer.scanInRange, I'm going to update Atom to use the native API just for Cursor.getCurrentWordBufferRange. That will fix the most immediate performance problem. Then later we can take on the more risky task of updating scanInRange.

/cc @nathansobo

[winstliu]

Ooh, this should really help performance for bracket-matcher's HTML tag matching as well!

[maxbrunsfeld]

this should really help performance for bracket-matcher's HTML year matching

Yeah, I've noticed some lag in bracket-matcher's searching. For bracket matcher we could probably even use the async search APIs, since the highlight doesn't need to appear synchronously.

[nathansobo]

@maxbrunsfeld Is this the slowness of Cursor.getCurrentWordBufferRange something you just noticed while profiling or is it actually in a code path related to autocompletion? I'm surprised this method gets called super frequently. I'm excited to see these optimizations coming.

[maxbrunsfeld]

Is this the slowness of Cursor.getCurrentWordBufferRange something you just noticed while profiling or is it actually in a code path related to autocompletion?

It's in the code path for autocompletion (with both the old and new providers) because we need to avoid returning the word under the cursor as an autocomplete suggestion.

[nathansobo]

Yee haa!