Re: Things I learned from form autofill profiling.

[Matthew N.]

Thanks Evelyn,

Forwarding to our public list so other interested parties can follow along.

On Fri, Apr 7, 2017 at 6:40 PM, Evelyn Hung <eh...@mozilla.com> wrote:

Hi form autofiller,

This is the profile I got by enabling a few prefs and test against this page.

Thank Mike for spending his time and guide me reading profiles. Here are a few findings to share. Just to be clear, this is my practice of learning profiler as Mike is so kind to teach me step by step. There isn't any performance concern for form autofill, and the following are more like nits that the team could dig into and improve.

1. We firstly noticed that 30ms(i.e. 2 frame drops) had been spending on IdentifyAutofillFields, and within this amount of time, 14ms was on collectFormFields. We were wondering if this time spending will be a linear growth by the form numbers or by the complexity of the DOM. We could find more complex cases and profile them. One possible optimization is, we probably can span the field collecting stuff across the time if possible, e.g. do it when the page is idle.

2. It seems the initialization above was triggered by DOMContentLoaded event; this might be not a good idea because it blocks the main thread which impacts layout and first paint. You may want to consider onload event instead.

​For 1 and 2 since we don't have autofill (where we fill the fields on load) like with password manager, only autocomplete from the dropdown, maybe we only need to identify autofill fields when a new FormLike gets focused. I think there may be problems with simply delaying our current code because I think we need to call markAsAutofillField before a field gets focused (unless we fixed that already?). If we don't have to worry about the markAsAutofillField timing then I think even a setTimeout(…, 0) approach after DCL/load would be useful though I think listening for focus events on input/select/textarea will still be most performant.

​

3. Linking to too many jsm files might be a problem because every jsm file is loaded into different compartments and crossing compartment access is time consuming. We haven't had a tool to precisely measure the overhead, but Ehsan is warning people to think twice about using jsm.

​Yeah, this is something we're aware of and have discussed and that's why we are already combining three objects in FormAutofillContent.jsm rather than ideally having them separated. ​On the opposite hand, using frame scripts also has overhead since there is duplication for each "tab"/"browser". We could possibly use loadSubScript or many convert some JSM to process scripts but it's never been clear to what extreme we need to avoid JSMs.

 

And two suggestions:

1. We grep "autofill" to filter interesting call stacks for investigation, but if you have profiler marker added in the code, you can get into your code point easier.

2. Try to profile on a low-end machine. I used my Mac Pro to profile this time, but there might be more interesting stories on a less powerful machine. Feel free to submit your profile here for analysis if you try on a low-end device.

@Mike, feel free to correct me if I misunderstood something. :-)

[Luke Chang]

Thanks Evelyn, too. Great information.

2017-04-08 6:56 GMT+08:00 Matthew N. <Ma...@mozilla.com>:

Thanks Evelyn,

Forwarding to our public list so other interested parties can follow along.

On Fri, Apr 7, 2017 at 6:40 PM, Evelyn Hung <eh...@mozilla.com> wrote:

Hi form autofiller,

This is the profile I got by enabling a few prefs and test against this page.

Thank Mike for spending his time and guide me reading profiles. Here are a few findings to share. Just to be clear, this is my practice of learning profiler as Mike is so kind to teach me step by step. There isn't any performance concern for form autofill, and the following are more like nits that the team could dig into and improve.

1. We firstly noticed that 30ms(i.e. 2 frame drops) had been spending on IdentifyAutofillFields, and within this amount of time, 14ms was on collectFormFields. We were wondering if this time spending will be a linear growth by the form numbers or by the complexity of the DOM. We could find more complex cases and profile them. One possible optimization is, we probably can span the field collecting stuff across the time if possible, e.g. do it when the page is idle.

2. It seems the initialization above was triggered by DOMContentLoaded event; this might be not a good idea because it blocks the main thread which impacts layout and first paint. You may want to consider onload event instead.

​For 1 and 2 since we don't have autofill (where we fill the fields on load) like with password manager, only autocomplete from the dropdown, maybe we only need to identify autofill fields when a new FormLike gets focused. I think there may be problems with simply delaying our current code because I think we need to call markAsAutofillField before a field gets focused (unless we fixed that already?). If we don't have to worry about the markAsAutofillField timing then I think even a setTimeout(…, 0) approach after DCL/load would be useful though I think listening for focus events on input/select/textarea will still be most performant.

Yeah, we already fixed the markAsAutofillField-after-focusing issue in Bug 1341582 so I second that listening for focus event.

[Luke Chang]

2017-04-08 12:14 GMT+08:00 Luke Chang <lch...@mozilla.com>:

Thanks Evelyn, too. Great information.

2017-04-08 6:56 GMT+08:00 Matthew N. <Ma...@mozilla.com>:

Thanks Evelyn,

Forwarding to our public list so other interested parties can follow along.

On Fri, Apr 7, 2017 at 6:40 PM, Evelyn Hung <eh...@mozilla.com> wrote:

Hi form autofiller,

This is the profile I got by enabling a few prefs and test against this page.

Thank Mike for spending his time and guide me reading profiles. Here are a few findings to share. Just to be clear, this is my practice of learning profiler as Mike is so kind to teach me step by step. There isn't any performance concern for form autofill, and the following are more like nits that the team could dig into and improve.

1. We firstly noticed that 30ms(i.e. 2 frame drops) had been spending on IdentifyAutofillFields, and within this amount of time, 14ms was on collectFormFields. We were wondering if this time spending will be a linear growth by the form numbers or by the complexity of the DOM. We could find more complex cases and profile them. One possible optimization is, we probably can span the field collecting stuff across the time if possible, e.g. do it when the page is idle.

2. It seems the initialization above was triggered by DOMContentLoaded event; this might be not a good idea because it blocks the main thread which impacts layout and first paint. You may want to consider onload event instead.

​For 1 and 2 since we don't have autofill (where we fill the fields on load) like with password manager, only autocomplete from the dropdown, maybe we only need to identify autofill fields when a new FormLike gets focused. I think there may be problems with simply delaying our current code because I think we need to call markAsAutofillField before a field gets focused (unless we fixed that already?). If we don't have to worry about the markAsAutofillField timing then I think even a setTimeout(…, 0) approach after DCL/load would be useful though I think listening for focus events on input/select/textarea will still be most performant.

Yeah, we already fixed the markAsAutofillField-after-focusing issue in Bug 1341582 so I second that listening for focus event.

I just noticed that some metrics should rely on "IdentifyAutofillFields" to determine whether a page contains autofill-able forms (e.g. bug 1341569, though I'm not sure whether a page should be treated as "with form" if no input inside has ever been focused). The setTimeout approach would be better if that is a problem.