548515 - Loading the BlindCoolTech site with NVDA takes over a minute, where it took at most 6 seconds in Firefox 3.6

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Marco Zehe (:MarcoZ)]

STR:
1. With NVDA running, load above URL.

Results:
1. In Firefox 3.6, NVDA starts responding at most 6 seconds after page load. The page has quite some content 81400 links or so), so it takes a bit.
2. In Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.3a2pre) Gecko/20100224 Minefield/3.7a2pre (.NET CLR 3.5.30729), the same page takes over a minute to load inth NVDA's virtual buffer.

Comment 1

[David Bolter [:davidb] (NeedInfo me for attention)]

Weird. Is this reproducible with other screen readers (or tools)?

Comment 2

[Marco Zehe (:MarcoZ)]

It is not happening with JAWS 11. JAWS 11 takes under a second in either Minefield or Firefox 3.. When loading the page for the first time, there is also no difference between the two Firefox builds.

Moreover, with NVDA, there are at least two steps. I was testing January builds, and they show a 20 second delay, while current nightlies show a more than 60 second delay. The 20 second delay seems to be an interim step on the way to the current situation.

Comment 3

[alexander :surkov (:asurkov)]

Marco, could you find regression ranges please?

Comment 4

[Marco Zehe (:MarcoZ)]

The first regression range is between the December 10, 2009, and December 11, 2009 builds:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e41f3b73ee3e&tochange=9af2a428dcb1

It implicates bug 342045, which is the only a11y bug that went in in this period.

Comment 5

[Marco Zehe (:MarcoZ)]

The second regression range, where it goes from about 20 seconds to over 1 minute for the page load, is between the January 11, 2010 and January 12, 2010 builds:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=120667a01fd2&tochange=a43e2f7eda8f
Possible bugs are bug 538633 or bug 532338. I think bug 538633 is the more likely candidate since bug 532338 only exposes some roles differently.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

I wonder if the webprogress is hitting nsAccessibilityService::OnStateChange a lot. Need to debug...

Comment 7

[alexander :surkov (:asurkov)]

Attachment: patch

Since these bugs were related with array usage to store accessible children then I assumed performance problems must be because of array's memory reallocation when new elements are appended. The patch set array capacity to avoid this. But the tests unfortunately don't show any performance win.

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch

previous patch was from other bug

Comment 9

[Marco Zehe (:MarcoZ)]

I just built with this patch, and it doesn't solve the problem. On the contrary, I have a feeling the performance declines by a few more seconds.

Comment 10

[alexander :surkov (:asurkov)]

Once I get windows 7 I'll do profiling. Now I don't have any idea what can be wrong.

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Did you find any hotpath(s)?

Comment 12

[alexander :surkov (:asurkov)]

I still can't get Windows.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

I tired exploring this site in accprobe and it took a lonnnng time for the document to fill up with children. No profiling on Win yet.

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

OK this was easier to recreate using NVDA (accprobe seems to often just fail to find children of the document). I ran a rudimentary profiler (Sleepy) but it doesn't give me call graphs. Highest function hit count was operator== between nsAccessible and nsIAccessible (nsRefPtr<t>)

We get a lot of warnings about attempting to look at an unregistered link (bug 556004)

I don't know what is going on. I wish I had Shark on windows.

Comment 15

[David Bolter [:davidb] (NeedInfo me for attention)]

(I meant call stacks)

Comment 16

[David Bolter [:davidb] (NeedInfo me for attention)]

Ah xperf! Hmmm no debugging symbols yet.

Comment 17

[alexander :surkov (:asurkov)]

(In reply to comment #14)
> OK this was easier to recreate using NVDA (accprobe seems to often just fail to
> find children of the document). I ran a rudimentary profiler (Sleepy) but it
> doesn't give me call graphs. Highest function hit count was operator== between
> nsAccessible and nsIAccessible (nsRefPtr<t>)

Right.

Total weight 52.95

operator==<nsAccessible;nsIAccessible>  18.13
nsTArray<nsRefPtr<nsAccessible> >::IndexOf<nsIAccessible *;nsDefaultComparator<nsRefPtr<nsAccessible>;nsIAccessible *> > 7.41
nsDefaultComparator<nsRefPtr<nsAccessible>;nsIAccessible *>::Equals 7.11
nsRefPtr<nsAccessible>::get  7.08
nsID::Equals 1.27
NS_TableDrivenQI 0.82
nsQueryInterface::operator() 0.37
nsGenericElement::QueryInterface 0.37

Comment 18

[alexander :surkov (:asurkov)]

[Root] 60.47
   |- xul.dll!CAccessibleHypertext::get_hyperlinkIndex 28.20
   |- xul.dll!CAccessibleHypertext::get_hyperlink 28.16
   |- ntdll.dll!_RtlUserThreadStart 1.74

Comment 19

[alexander :surkov (:asurkov)]

I hope bug 560013 will fix this bug.

Comment 20

[alexander :surkov (:asurkov)]

The current build makes to load blindcooltech.com more than 10 minutes on my machine, it takes 40 seconds with the patch of bug 560013. Assuming my virtual windows 7 machine is slower than Marco's one in 10 times then bug 560013 should fix the regression.

However get_hyperlinkIndex and get_hyperlink are very unoptimized since they require o(n^2) to get all hyperlinks and hyperlink offsets for the hypertext accessible, where n is hypertext accessible children count. We could use caching to make them performant and get o(m) where m is amount of hyperlinks within hypertext accessible but it might be a pain to keep cache updated since we need to watch text nodes changes to update hyperlink offsets. Probably the best way would be to request a changes in IA2 API to get o(n) order if hyperlink offsets and hyperlinks are returned in the array.

Comment 21

[alexander :surkov (:asurkov)]

(In reply to comment #20)
> Probably the
> best way would be to request a changes in IA2 API to get o(n) order if
> hyperlink offsets and hyperlinks are returned in the array.

I filed question to IA2 group - https://lists.linux-foundation.org/pipermail/accessibility-ia2/2010-April/001106.html

Comment 22

[Marco Zehe (:MarcoZ)]

Fixed by bug 560013.

Comment 23

[Marco Zehe (:MarcoZ)]

Verified WFM Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.3a5pre) Gecko/20100420 Minefield/3.7a5pre (.NET CLR 3.5.30729)

Comment 24

[alexander :surkov (:asurkov)]

fixed per comment #22.