Suggestions Rendering Performance

[as-cii]

Typing a character in Atom involves three main operations: keeping the model up to date, rendering the newly inserted character, and showing suggestions for the current word. These tasks are summarized by the following CPU profile (captured on a real-world JavaScript file with ~ 3000 lines):

In this example autocomplete-plus blocked the main thread for 34.7ms and occupied 68% of the entire profile. It's worth noting that during that amount of time, Atom could have rendered two more animation frames.

There are two main reasons why this code path took so long:

1. Fetching suggestions is unnecessarily complex and slow. Instead of storing and indexing symbols along with their tokens when the buffer changes, we could simply search for all the occurrences of a certain pattern and then query those locations to get the syntax information. The search can be done in C++, which should scale quite nicely as the file gets bigger. A second step here could be to investigate some indexing data structures (such as suffix trees/arrays) to speed this up even further.
2. Rendering suggestions uses obsolete techniques and displays too many items. The current manual DOM manipulation should be replaced with an etch component that takes care of efficiently rendering an infinite scrolling list, swapping elements in and out as the user scrolls.

/cc: @atom/maintainers

[nathansobo]

Nice summary. Excellent graphical treatment on the profile.

[benogle]

Lol. Apologies. Excited for faster autocomplete. 👍

[leroix]

Just wanted to drop an update here. We've moved subsequence searching into a native function that searches in a background thread. We've also made a bunch of rendering optimizations, so the amount of rendering we do on each key stroke is fairly minimal.

#911
#904
#900
atom/atom#15954
atom/atom#15894

[nathansobo]

Are we good enough to close this out?

[leroix]

There's still some stuff in https://github.com/atom/autocomplete-plus/blob/master/lib/provider-config.js that I want to try to further optimize, but I think we're in pretty good shape here as it stands.

Also notable performance PRs:
atom/superstring#44
atom/superstring#45