1258946 - Grammarly Firefox add-on is really, really slow in GMail composer

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Grammarly ( https://grammarly.com/ ) comes with an add-on that injects itself into the text boxes.

Unfortunately, it is really really slow on Firefox compare to Chrome. It almost made Firefox unusable.

I don't have a contact to the site, but as an exercise to understanding Firefox performance, I would like to find out what we have available to find out what slow down the add-on, and maybe improve Gecko accordingly (or, actually contacts w/ their engineering to workaround the issues).

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

BTW I am on Aurora w/ e10s turned on. So things readily available did not make it better.

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

This is the Gecko Profiler data I collected.

https://cleopatra.io/#report=4b20328707d90fb7036aa8f14a13df5ded43631d&jankOnly=true&javascriptOnly=true&filter=%5B%7B%22type%22%3A%22RangeSampleFilter%22,%22start%22%3A2182217,%22end%22%3A2192577%7D%5D&selection=0,995,2900,3193,3194,3195,3196,8145,8151,8167,9232,9233,9107,9243

A lot of time are indeed spent in Grammarly.

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

While it is also slow on Bugzilla <textarea>, for example, the contenteditable in GMail composer is the slowest.

Comment 4

[Desigan Chinniah [:cyberdees] [:dees] [London - GMT]]

Any possibility for someone to further investigate here :naveed? We've also got a direct communication line for some of the Gmail folks if that's useful.

Comment 5

[Andrew Overholt [:overholt]]

Ehsan, this is the bug we were talking about.

Comment 6

[(no longer active)]

Here is a profile that I captured myself: https://perfht.ml/2paZwYT

I'm not really sure what to do with this bug...  :(  I think bug 613498 plays a big role here, but I don't know what's the best way to evaluate the pure XRay overhead in cases like this.  Bill, Boris, I'd appreciate if you can also have a look at the profile and see if you can spot anything I couldn't?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Filtering that profile on "Xray" shows pretty much no time spent under those....

I'll try and see whether I can reproduce this, I guess.

Comment 8

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

You have to scroll down to the fourth tab process. Time spent in xrays there is... quite a lot.

I did think of one thing here. In bug 1334263, Kris mentioned that WebExtensions would prefer if expandos were shared between sandboxes from the same add-on (so, same principals). That would actually save us a little work since we could remove the exclusive global check and, importantly, the cost of wrapping the exclusive global. We might only be able to do this for WebExtensions though. Not sure.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> You have to scroll down to the fourth tab process

Ah, I see.  Yes, there's definitely some Xray time there.  It's hard to figure out how it breaks down because of all the garbage JS stackframes.  I wish we could get a fix for <https://github.com/devtools-html/perf.html/issues/238>; it would make profiling a lot more effective.

I _think_ the slowness is mostly due to expando handling in Xrays, but it's really hard to tell for sure.

One experiment worth checking is changing our code to always hand out transparent CCWs instead of Xrays and seeing how performance is affected...

Comment 10

[(no longer active)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #9)
> > You have to scroll down to the fourth tab process
> 
> Ah, I see.  Yes, there's definitely some Xray time there.  It's hard to
> figure out how it breaks down because of all the garbage JS stackframes.  I
> wish we could get a fix for
> <https://github.com/devtools-html/perf.html/issues/238>; it would make
> profiling a lot more effective.
> 
> I _think_ the slowness is mostly due to expando handling in Xrays, but it's
> really hard to tell for sure.
> 
> One experiment worth checking is changing our code to always hand out
> transparent CCWs instead of Xrays and seeing how performance is affected...

We decided instead of doing this waiting for the issue mentioned above to be fixed and retry looking at the profile...

Comment 11

[Jorge Villalobos [:jorgev] (he/him)]

Mass-closing bugs that relate to legacy versions of add-ons or are otherwise no longer worth tracking. Please comment if you think this bug should be reopened.

Sorry for the bugspam. Made you look, though!