1901204 - Accessibility slows down the JSON viewer dramatically

Status: NEW

(Core :: Disability Access APIs, defect, P3)

Description

[Florian Quèze [:florian]]

Attachment: profile.json

Steps to reproduce:

• Have Firefox with accessibility enabled (I don't know why it is enabled on my Firefox instance, but whatever...)
• Load the attached JSON file in the built-in JSON viewer of Firefox.
• Expand or close the large (32k elements) array threads->0->samples->time

Expected results: it appears within a reasonable amount of time (immediately would be nice, but the devtools code is not fast enough for that, so let's say it should appear within about 5 seconds).

Actual result: on my fast M1 Max Macbook Pro, 29 secondes to show the content of the array, 22 seconds to hide it.

Profiling shows that 74% of the CPU time is spent in accessibility code: https://share.firefox.dev/4c4TmRm

Additionally, DocAccessible::ContentRemoved misses a profiler label frame to let the profiler know we are in accessibility code (the profiler shows the "Layout: Frame Construction" category).

Comment 1

[Eitan Isaacson [:eeejay]]

I'm calling this an S2.

Comment 2

[James Teh [:Jamie]]

This is nowhere near as bad on my system, though obviously anything we can do to do better is a good thing. This profile shows opening the node in question:

https://share.firefox.dev/3KBohco

I suspect this is due to the fix for bug 1898661, which is in 128 but not 127. In the profile in comment 0, we see a lot of time spent walking AttrRelProvider arrays. Before the fix for bug 1898661, the Dev Tools tree unnecessarily inserted aria-labelledby references for every single tree cell linking to the same headers, which meant we would have had tens of thousands of AttrRelProvider entries to examine every time we needed a reverse relation. After bug 1898661, those aria-labelledby references are gone, so the AttrRelProvider arrays aren't huge any more.

:florian, is this significantly better for you in Nightly?

Putting aside the JSON viewer specifically (where this issue has been fixed), I'm not sure how we can realistically do better with a lot of aria-labelledby references. I guess we could partition the arrays further so that rather than effectively having this:

{
  "target": [
    ["aria-labelledby", sourceNode1],
    ["aria-labelledby", sourceNode2],
    ["label", sourceNode3]
  ]
}

We instead would have this:

{
  "target": [
    ["aria-labelledby", [
      sourceNode1,
      sourceNode2
    ]],
    ["label", [
      sourceNode3
    ]]
  ]
}

This would mean that if we wanted the reverse relation for "label", we wouldn't have to walk through the reverse relations for "aria-labelledby" to get it. But that still doesn't deal with the cost of getting a reverse relation for aria-labelledby (though we don't really do that when caching), nor the cost of maintaining such large arrays.

Comment 3

[James Teh [:Jamie]]

Downgrading to s3 given comment 2.