Bugzilla

STR (with NVDA):

1. Enable CTW and restart Firefox.
2. Open https://www.jantrid.net/
3. View source.
4. Press NVDA+f5 to refresh NVDA's buffer.
    - Expected: It takes a fraction of a second.
    - Actual: It takes more than a second.
5. Repeat with CTW disabled.
    - Observe: It takes a fraction of a second.

This is the first time I've seen CTW perform worse than non-CTW on Windows. However, it's likely that there are significant perf gains to be had across the board based on the learnings from this.

Profile: https://share.firefox.dev/3LnP6zF

This is much, much worse on bigger pages. That page only has a few hundred lines fo code. Even on a Bugzilla bug with about 20 comments, there are several thousand lines of code, and the buffer takes minutes to render.

In the spirit of "start simple and optimise later", I didn't port the HyperText offset cache from HyperTextAccessible when I was implementing HyperTextAccessibleBase. It wasn't clear to me how much we needed this optimisation. Well, it turns out we do.

The thing that's unique about view source is that it has one single container with many children (6403 in this example). That's because of all the syntax highlighting, which creates many little text nodes. Because this is such a large HyperText container, calculating the offset for each node is pretty expensive, since we have to walk through the child nodes accumulating the text length. That's O(n^2) at best, and on a page like this, n is biiig.

The algorithm for this offset cache isn't particularly difficult. What's tricky here is that it's hard to use a common cache across the local and remote code because we cache differently for local and remote. Local doesn't have mCachedFields, which is a nice place to store this so we don't waste memory in RemoteAccessibles that don't need this.

STR (with NVDA):

1. Enable CTW and restart Firefox.
2. Open https://www.jantrid.net/
3. View source.
4. Press NVDA+f5 to refresh NVDA's buffer.
    - Expected: It takes a fraction of a second.
    - Actual: It takes more than a second.
5. Repeat with CTW disabled.
    - Observe: It takes a fraction of a second.

This is the first time I've seen CTW perform worse than non-CTW on Windows. However, it's likely that there are significant perf gains to be had across the board based on the learnings from this.

Profile: https://share.firefox.dev/3LnP6zF

This is much, much worse on bigger pages. That page only has a few hundred lines of code. Even on a Bugzilla bug with about 20 comments, there are several thousand lines of code, and the buffer takes minutes to render.

In the spirit of "start simple and optimise later", I didn't port the HyperText offset cache from HyperTextAccessible when I was implementing HyperTextAccessibleBase. It wasn't clear to me how much we needed this optimisation. Well, it turns out we do.

The thing that's unique about view source is that it has one single container with many children (6403 in this example). That's because of all the syntax highlighting, which creates many little text nodes. Because this is such a large HyperText container, calculating the offset for each node is pretty expensive, since we have to walk through the child nodes accumulating the text length. That's O(n^2) at best, and on a page like this, n is biiig.

The algorithm for this offset cache isn't particularly difficult. What's tricky here is that it's hard to use a common cache across the local and remote code because we cache differently for local and remote. Local doesn't have mCachedFields, which is a nice place to store this so we don't waste memory in RemoteAccessibles that don't need this.