STR: 1. With VoiceOver on, load http://www.heise.de/mac-and-i 2. Wait until VoiceOver announces "HTML content". 3. Press CTRL+Option+Shift+DownArrow to start interaction and start reading the content. Result: On my 2.7 gHz Core I5 MacBook pro, VoiceOver will now say "Firefox Nightly busy", and it will not come back with any other reaction for 50 (that's fifty) seconds. Then, it will say "Firefox Nightly Ready". Smaller pages like the Firefox start page are faster, the more content on a page, the slower it gets.

How long should I wait between 1 and 2?

OK I think this is a relevant profile: http://is.gd/lpj44g

Profiling data for the above testcase (I hope): http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv97136_DJZNJppKqXAFKuvXGZAJjZMGwQ9dM9_ELKFOLK6jL6haeCLQycU1KBjYttMX76B_z8wp29s4mQtg_sLmsA8TnIlg5rB6xvt1eLq3FH7P47hLJE5ExhBj1Xa8q4IFS9n2hV-x5FNf9946WTTn1nS0tHA

Yes our profiles are similar.

When I run this on debug, one of the stack trace I find taking some time (not that much, but still) is bug 768997. It is a regression.

(In reply to Hub Figuiere [:hub] from comment #5) > When I run this on debug, one of the stack trace I find taking some time > (not that much, but still) is bug 768997. It is a regression. profiling debug builds is basically pointless. That code is only in debug builds which aren't the issue we care about here, so its not relevent.

Marco, is it a debug build or a release build you use?

Release, regular nightly. I usually test with that to get as close to the end user experience as possible. Unless I note otherwise, you can always assume I run a release build.

Comment on attachment 652865 [details] [diff] [review] Implement accessibilityArrayAttributeCount for mozPaneAccessible. r= This one remove some "noise" in the performance analysis. A trivial performance improvement.

Comment on attachment 652865 [details] [diff] [review] Implement accessibilityArrayAttributeCount for mozPaneAccessible. r= > >+- (NSUInteger)accessibilityArrayAttributeCount:(NSString *)attribute nit type* name >+ if([attribute isEqualToString:NSAccessibilityChildrenAttribute]) { >+ return mGeckoAccessible->ChildCount() ? 1 : 0; I think you could just use FirstChild() here which would be a bit faster. >+ } nit, no braces

I don't think FirstChild() would be faster. ChildCount() just call mChildren.Length().

Comment on attachment 652947 [details] [diff] [review] Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. r= Dealt with the 'nit from Trevor.

(In reply to Hub Figuiere [:hub] from comment #13) > I don't think FirstChild() would be faster. ChildCount() just call > mChildren.Length(). true, but its virtual, FirsChild isn't

Comment on attachment 652947 [details] [diff] [review] Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. r= Review of attachment 652947 [details] [diff] [review]: ----------------------------------------------------------------- r=me with my and Trevor's comments addressed ::: accessible/src/mac/mozActionElements.mm @@ +342,5 @@ > +{ > + if (!mGeckoAccessible) > + return 0; > + > + if([attribute isEqualToString:NSAccessibilityChildrenAttribute]) nit: space after if please add a comment that this is a performance trick because mozPaneAccessible doesn't keep its child in the cached children array

(In reply to Trevor Saunders (:tbsaunde) from comment #16) > (In reply to Hub Figuiere [:hub] from comment #13) > > I don't think FirstChild() would be faster. ChildCount() just call > > mChildren.Length(). > > true, but its virtual, FirsChild isn't FirstChild() calls GetChildAt() (inline) GetChildAt() (virtual) calls mChildren.SafeElementAt() which call nsTArray<>::Length().

(In reply to Hub Figuiere [:hub] from comment #18) > (In reply to Trevor Saunders (:tbsaunde) from comment #16) > > (In reply to Hub Figuiere [:hub] from comment #13) > > > I don't think FirstChild() would be faster. ChildCount() just call > > > mChildren.Length(). > > > > true, but its virtual, FirsChild isn't > > FirstChild() calls GetChildAt() (inline) > GetChildAt() (virtual) calls mChildren.SafeElementAt() which call > nsTArray<>::Length(). err, yeah, I should have said ContentChildCount(), but I'm not absolutely sure I think that's a good idea to use here (we should clarify exactly when we support using that).

Yeah maybe we can use ContentChildCount() as I believe we'll only encounter that kind of child (it is not a treeview or something)

Comment on attachment 653520 [details] [diff] [review] Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. use ContentChildCount() instead of ChildCount. Other nits addressed.

Comment on attachment 653520 [details] [diff] [review] Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. Review of attachment 653520 [details] [diff] [review]: ----------------------------------------------------------------- ::: accessible/src/mac/mozActionElements.mm @@ +338,5 @@ > > @implementation mozPaneAccessible > > +// By default this calls -[[mozAccessible children] count]. > +// Since we don't cache mChildren find a faster way. it makes sense to move this comment to the code it's about, i.e. before that if statement. I assume this method might be used to speed up other properties as well. @@ +345,5 @@ > + if (!mGeckoAccessible) > + return 0; > + > + if ([attribute isEqualToString:NSAccessibilityChildrenAttribute]) > + return mGeckoAccessible->ContentChildCount() ? 1 : 0; I wouldn't use ContentChildCount() until it's a real bottleneck.

Comment on attachment 653752 [details] [diff] [review] Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. Using ChildCount() again.

Comment on attachment 653752 [details] [diff] [review] Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. ># HG changeset patch ># User Hubert Figuière <hfiguiere@mozilla.com> ># Date 1342052959 25200 ># Node ID 072e6d50c5c30910919301d0051fb69ac14bd63e ># Parent 75ed4a4cc1024e35dd3577e52d818face035c2b7 >Bug 772060 - Part 1: Implement accessibilityArrayAttributeCount for mozPaneAccessible. r=surkov,tbsaunde > >diff --git a/accessible/src/mac/mozActionElements.mm b/accessible/src/mac/mozActionElements.mm >--- a/accessible/src/mac/mozActionElements.mm >+++ b/accessible/src/mac/mozActionElements.mm >@@ -333,16 +333,29 @@ enum CheckboxValue { > [mTabs release]; > mTabs = nil; > } > > @end > > @implementation mozPaneAccessible > >+- (NSUInteger)accessibilityArrayAttributeCount:(NSString*)attribute >+{ >+ if (!mGeckoAccessible) >+ return 0; >+ >+ // By default this calls -[[mozAccessible children] count]. >+ // Since we don't cache mChildren find a faster way. find a faster way is a little funny phraseing to me, how about "so this is faster"

Backed out because it landed on a burning tree https://hg.mozilla.org/integration/mozilla-inbound/rev/46365c62935c

Marcoz, is this still an issue? It is the last open bug blocking meta bug 454202

Yes, and there are probably many more since this got filed. Mac isn't a priority for us right now, so I wouldn't count on that dependency tree to be accurate.