The attached test case produces a table with 1000 rows and 2 columns. It produces either an HTML table or an ARIA table based on the ARIA_TABLE boolean set in the file. I tested both and recorded the NVDA buffer refresh time (NVDA+f5) logged by NVDA for each one:

• HTML table: Buffer load took 1.637 sec, 11786 chars
• ARIA table: Buffer load took 5.757 sec, 11786 chars

So ARIA tables are > 3.5x slower than HTML tables!

Because the table exposed to NVDA is identical - only the Gecko implementation is different - we can conclude that our ARIA table implementation is slooooooow. 🐌 I suspected as much; we don't do any caching of cell coordinates, so we end up walking the tree for every coordinate query on every cell.

Practically, this means we totally suck in Searchfox. We already suck in large tables because of the e10s cross-process chattiness, but this makes us suck even more.

Reminder, after bug 1619383, to also look into group position performance and caching.

After the fix for bug 1638238, the difference between HTML tables and ARIA tables is nowhere near as significant. For the 1000 row table I mentioned in comment 0, NVDA now takes ~1.1 sec to render the ARIA table and ~1.0 sec to render the HTML table. At 10000 rows, the difference is more noticeable, with the ARIA table taking ~22.5 sec and the HTML table taking ~16.9 sec. So, this is probably still worth doing, but not quite as important as before.

I think this is because TableCellAccessible::ColHeaderCells previously fetched the row index on every row it walked when fetching headers. Now that we cache headers, the row index gets queried much, much less.

Real world page where this might matter (~9000 row ARIA table):
https://searchfox.org/mozilla-central/source/widget/windows/nsWindow.cpp

This is fixed by CachedTableAccessible.