How We Optimize Efficiency for the Grammarly Textual content Editor SDK
[ad_1]
Whether or not your customers are writing brief paragraphs or pages of textual content, you possibly can combine the Grammarly Textual content Editor SDK to counsel enhancements for grammar, readability, and extra. To supply the identical high-quality expertise regardless of the phrase depend, the Grammarly for Builders engineering crew is all the time searching for out methods to optimize the SDK’s efficiency.
On this article, we’ll cowl three methods the crew makes use of to hurry up the SDK and Textual content Editor Plugin so options render shortly.
Background: How the mixing works
To know how we optimize the SDK, let’s first assessment how the mixing works in your app. You should use the SDK so as to add the Grammarly Textual content Editor Plugin to a number of textual content editors or textual content fields in your software. Then, as your customers kind in these editors, the plugin sends their textual content to Grammarly’s back-end and retrieves options.
To indicate customers the place Grammarly has a suggestion, the plugin underlines the related textual content within the editor. The plugin doesn’t edit your DOM in any approach—as a substitute, it renders underlines in an invisible layer on high of the viewport utilizing shadow DOM. This implies we have to regularly replace the positions for underlines in order that they keep synced with the textual content.
Drawback: Lengthy paperwork can current efficiency challenges
Rendering underlines in actual time as a consumer is actively modifying a doc is a posh engineering downside. Suppose a consumer inserts a phrase—all subsequent underlines must shift accordingly. Updating the underline positions effectively is particularly difficult when working with lengthy texts, the place a lot of calculations must be made.
Resolution: Efficiency optimizations
We’ve made three efficiency optimizations that assist us present options shortly for lengthy texts.
1
Prioritize underlines within the viewport
The naive method to rendering underlines can be to rerun the whole doc by the Grammarly back-end every time there’s an edit and replace all of the underlines without delay.
This method clearly doesn’t scale to lengthy texts. To get round this downside, we prioritize rendering the underlines which can be seen to the consumer: that’s, the underlines within the editor’s viewport. The viewport will all the time be a hard and fast dimension, whatever the doc’s size. In fact, the consumer could scroll, so subsequent underlines get prioritized in keeping with their distance from the viewport.
This method interprets to different optimizations in our SDK. For instance, we solely fear about mouse occasions associated to underlines inside the viewport.
2
Scan for edits centered on the cursor
To replace underlines, we have to know when the textual content within the editor has modified. One technique for detecting modifications can be to repeatedly compute the diffs between the present doc and a earlier model from seconds in the past. Nevertheless, for very lengthy paperwork, diffs can be costly to calculate.
As a substitute of taking diffs between edited variations of a doc, we acknowledged that more often than not, the consumer will both be inserting or deleting characters from the cursor place. This turned the premise for a heuristic that considerably improved efficiency. We will seek for modifications from the cursor place and replace underlines accordingly somewhat than diffing the whole doc.
For example, if a consumer deletes one phrase, we are able to detect that change on the present cursor place and alter underlines accordingly.
3
Batch operations to cut back rendering work finished by the browser
To keep away from introducing any lag into your app, we need to keep away from holding the foremost UI thread for greater than 5 milliseconds. If a course of takes longer, we have now timekeeping logic to yield the CPU again to the primary thread to course of the subsequent animation body.
We have to use these 5 ms very effectively to render updates shortly for lengthy texts. Initially, we found an issue: After we made any fashion modifications, corresponding to drawing underlines in a brand new location, we might set off a “format” section within the browser’s pixel pipeline, inflicting it to do considerably extra work. We would have liked to maintain these format cycles to an absolute minimal.
We realized that we may batch up operations as follows:
- First, we do a sequence of measurement operations, corresponding to
getBoundingClientRect()
. That is essential to pinpoint the fitting underline place and dimension, since we don’t have direct entry to details about the fashion or dimension of the textual content within the editor. - Then, we do one huge “mutate” operation the place we redraw the underlines. This ensures that we have now at most one format section every time we do 5 ms of labor.
Outcomes
We monitor efficiency in simulated text-editing periods on a big textual content (8,000+ phrases), and on the 99th percentile, the CPU time utilized by the SDK is lower than 5 ms per animation body. As a result of prioritizing underlines within the viewport, we anticipate that underlines within the viewport will sometimes render inside one body of scrolling in observe.
Need to tell us the way you’re utilizing the SDK and what the efficiency has been like? You can begin a dialogue in our GitHub repository—we’re there to reply any questions you may need.
The publish How We Optimize Efficiency for the Grammarly Textual content Editor SDK appeared first on Grammarly Weblog.
[ad_2]