Make ChromeVox navigation 100x faster on some sites.

Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and out of V8 as was advised by others in the past. Since the major native rewrite of automation into C++, there hasn't been a good illustration of the actual perf implications until now.

The issue.
The current implementation of AutomationNode.children makes a call to native to fetch child id's per child. On a large site, where a node has many children, this adds up quickly. Since the actual js objects are created on the initial node data event, it's not js object creation causing any perf issues.

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like incremental search take about a few minutes to find a text match.

Mitigation
Since ChromeVox rarely needs to ask for children, we are fine with using next/previous sibling. The previous impl of sibling traversal relies upon asking for the parent's children. This cl changes it so we directly ask the native bindings for the child id at index.

With this change, next/previous sibling calls take about 0
ms.

BUG=636954
Committed: https://crrev.com/6247dd22f8cc3628271a6ca5e818042c73772714
Cr-Commit-Position: refs/heads/master@{#411412}

[David Tseng, 2016-08-11 16:05:25]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.

The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. Since the actual js objects are created on the
initial node data event, it's not js object creation. 

The data

On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 200 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

BUG=636954
==========

[David Tseng, 2016-08-11 16:05:25]

dtseng@chromium.org changed reviewers:
+ dmazzoni@chromium.org

[David Tseng, 2016-08-11 16:06:10]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.

The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. Since the actual js objects are created on the
initial node data event, it's not js object creation. 

The data

On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 200 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

BUG=636954
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.

The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. Since the actual js objects are created on the
initial node data event, it's not js object creation. 

The data

On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 200 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

[David Tseng, 2016-08-11 18:46:21]

dtseng@chromium.org changed reviewers:
+ nektar@chromium.org

[David Tseng, 2016-08-11 18:47:02]

+ nektar. Nektarios, Dominic's ooo, can you have a look? It's pretty short and
should be understandable.

[David Tseng, 2016-08-11 18:51:31]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.

The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. Since the actual js objects are created on the
initial node data event, it's not js object creation. 

The data

On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 200 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues. 

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 200 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

[David Tseng, 2016-08-11 18:54:29]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues. 

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 200 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues. 

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

[dmazzoni, 2016-08-11 19:09:46]

lgtm

Neat! Any other calls to children()
we could optimize?

[nektarios, 2016-08-11 19:17:54]

lgtm

[David Tseng, 2016-08-11 19:23:06]

The CQ bit was checked by dtseng@chromium.org

[commit-bot: I haz the power, 2016-08-11 19:23:52]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-11 20:08:29]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues. 

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues. 

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

[commit-bot: I haz the power, 2016-08-11 20:08:32]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-08-11 20:10:13]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues. 

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0 
ms.
BUG=636954
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues.

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0
ms.
BUG=636954

Committed: https://crrev.com/6247dd22f8cc3628271a6ca5e818042c73772714
Cr-Commit-Position: refs/heads/master@{#411412}
==========

[commit-bot: I haz the power, 2016-08-11 20:10:14]

Patchset 1 (id:??) landed as
https://crrev.com/6247dd22f8cc3628271a6ca5e818042c73772714
Cr-Commit-Position: refs/heads/master@{#411412}

[David Tseng, 2016-08-11 22:50:33]

Description was changed from

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes several calls to
native to fetch child id's. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues.

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation

Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0
ms.
BUG=636954

Committed: https://crrev.com/6247dd22f8cc3628271a6ca5e818042c73772714
Cr-Commit-Position: refs/heads/master@{#411412}
==========

to

==========
Make ChromeVox navigation 100x faster on some sites.

It turns out that there is a very tangible cost to context switching into and
out of V8 as was advised by others in the past. Since the major native rewrite
of automation into C++, there hasn't been a good illustration of the actual perf
implications until now.

The issue.
The current implementation of AutomationNode.children makes a call to native to
fetch child id's per child. On a large site, where a node has many children,
this adds up quickly. Since the actual js objects are created on the initial
node data event, it's not js object creation causing any perf issues.

The data
On a site like blindcooltech.com:
there are about 4000 children of the root in the automation tree.

root.children takes around 60 ms.
Next/previous sibling calls to any child of root  takes around 100 ms.

This results in a significant lag when navigating the site and things like
incremental search take about a few minutes to find a text match.

Mitigation
Since ChromeVox rarely needs to ask for children, we are fine with using
next/previous sibling. The previous impl of sibling traversal relies upon asking
for the parent's children. This cl changes it so we directly ask the native
bindings for the child id at index.

With this change, next/previous sibling calls take about 0
ms.

BUG=636954

Committed: https://crrev.com/6247dd22f8cc3628271a6ca5e818042c73772714
Cr-Commit-Position: refs/heads/master@{#411412}
==========