text.getAttributes() can take an extraordinarily long time to return given a sufficiently large text object.




Disability Access APIs
10 years ago
2 years ago


(Reporter: Joanmarie Diggs, Unassigned)


(Blocks: 2 bugs, {access, perf})

access, perf
Dependency tree / graph
Bug Flags:
blocking1.9.1 -

Firefox Tracking Flags

(Not tracked)



(2 attachments)



10 years ago
Steps to reproduce:

1. Load the test case
2. Launch Accerciser
3. In Accerciser's tree of accessibles, highlight the document
   frame (note, Accerciser might take a few seconds to respond)
4. In Accerciser's iPython console type the following:

    text = acc.queryText()<Return>

Expected results: getAttributes() would return instantly.

Actual results: getAttributes() takes at least 6 seconds and sometimes 8 seconds to return.

Specs of the box where I tried this: AMD Athlon 64 X2 (Dual Core) 4200+ with 4GB RAM.

Granted, to highlight the issue I did place all of the text from "War and Peace" in the document frame object which is rather extreme. :-) But please bear with me BECAUSE:

1. There aren't even any text attributes present other than the
   default. All I did was copy and paste the contents and add
   <br /> tags. It's taking 6-8 seconds on a box with a dual
   core processor and 4 GB RAM to find out that, sure enough,
   there are no non-default text attributes. :-)

2. If you paste all of the content into a Gedit document and
   repeat the test, getAttributes() returns *instantly.*

3. If you open the test case in Gedit (with syntax highlighting
   enabled) and spot-check different offsets, getAttributes()
   returns *instantly* (correctly reporting the attributes).

Thus it would seem to be a Firefox/Mozilla bug. That leaves the question of, does this actually occur "in the wild"? The answer seems to be "yes and no." Michael Pedersen (who I believe is on the browser-china-atf alias, and who should feel free to chime in) has pointed out examples of eBooks (Bookshare as I recall) and also certain search results from the Library of Congress' National Library Service (aka the Braille and Talking Book folks) digital download catalog.

Due to various and sundry issues with passwords, copyright, and the like, I couldn't make a test case based on those. However, it seems that there are at least a healthy number of eBooks with sufficiently large text objects to make this a problem. Not an 6-8 second problem, but, say, a 1-2 second problem. Still too long for getAttributes() to return I would argue. 

In addition, considering real-world cases, given a line with a single bold word in the middle, there are three segments of text for which attributes must be obtained rather than one. Add another bold word somewhere else in the middle of that line, and now we're up to five segments. If getAttributes() took only a quarter of a second to return, that's still over a full second to get the text attributes for one line of text with a couple of bold words. :-(

Sorry to be long-winded in my report, and thanks VERY much in advance for taking a look at it!!


10 years ago
Blocks: 340809

Comment 1

10 years ago
also, see bug 445677 and bug 445509

Comment 2

10 years ago
Heh. Bugzilla wouldn't let me upload it as html -- or even zipped up -- due to size. :-) So I put it on my server instead. Your test case choices are:

* http://grain-of-salt.com/foo/wnp.html.zip
* http://grain-of-salt.com/foo/wnp.html

Thanks again!!
No longer blocks: 340809


10 years ago
Keywords: perf

Comment 3

10 years ago
Thanks Alexander. My plan was to comment on those bugs instead of filing this one. But I had initially made the 274 instances of the string "war" "<b>war</b>" and in doing so managed to hang Accerciser, hang Firefox, and cause the AT-SPI registry daemon to segfault by asking for the text attributes. :-) After that, I figured it seemed worthy of a dedicated bug. ;-)
Keywords: perf

Comment 4

10 years ago
Confirmed also on Windows. It takes 4 to 5 seconds on my Intel Core2Duo 2.67 gHz with 3 GB of RAM and Windows XP using AccProbe.
OS: Linux → All
Hardware: PC → All

Comment 5

10 years ago
Do I understand right you call text.getAttributes on document accessible?

Comment 6

10 years ago
Yes and no.... We call text.getAttributes on the accessible which contains the text of interest. Often that's a paragraph or a section or a heading or .... However, we still find plenty of pages where the text of interest is not inside any such object but instead directly in the page's body, i.e. document frame. In that case, yes indeed we'd wind up calling text.getAttributes on the document accessible.

Comment 7

10 years ago
Ok. So
1) Run through accessible tree (may help a bit because a11y tree is subset of DOM tree)
2) Do not walk into embedded char object (should bring big help but see bug 445677 comment #5)
3) Do not walk whole subtree every time for every text attribute (I suppose it should bring main performance win, in several times)


10 years ago
Flags: blocking1.9.1?
Keywords: perf
I don't see this as blocking 1.9.1.  Please re-nom if you disagree.  1.9.1 is a time-based release with a clear set of features defining the release.  This seems like an edge case that wouldn't hold back the release.
Flags: blocking1.9.1? → blocking1.9.1-

Comment 9

10 years ago
Joanie, can you explain again why you have to consume all text attributes at the doc level for support of text attributes in Orca?


10 years ago
Blocks: 340809
What's the status of this bug, since bug 475522 was fixed?

Comment 11

9 years ago
(In reply to comment #10)
> What's the status of this bug, since bug 475522 was fixed?

NEW, we need to fix bug 445677 firstly.

Comment 12

8 years ago
(In reply to comment #11)
> (In reply to comment #10)
> > What's the status of this bug, since bug 475522 was fixed?
> NEW, we need to fix bug 445677 firstly.

Bug 445677 patch is ready, it makes this testcase faster in 8 times. Originally it takes 4 seconds, after it takes .5 seconds on my machine.

Comment 13

8 years ago
It stills takes ~4 secs with trunk from today. I did a simple profiling with sysprof and most of the ff4 cpu time is spent on call(s) to nsTextAttrsMgr::GetRange, and internally, that function seems to spend most of the cpu time in in Equal and TextLength funcs.

I'm attaching the sysprof xml log and a quick screenshot

Comment 14

8 years ago
Created attachment 505070 [details]
Sysprof xml data (zipped)

Comment 15

8 years ago
Created attachment 505071 [details]
Screenshot of profiling data for quick view

Comment 16

8 years ago
(In reply to comment #15)
> Created attachment 505071 [details]
> Screenshot of profiling data for quick view

Notice that those numbers are for the whole cpu time and firefox cpu time is 87,19
Fer, did you profile on a non-debug build?

Comment 18

8 years ago
good catch. Repeating with optimized non-debug build
You need to log in before you can comment on or make changes to this bug.