Reassigning to Joanie -- Joanie, we can talk about pushing out other non-performance and non-regression type stuff that's on your plate.  If this particular bug is also not very high priority, we can push it out, too.

Created attachment 105664 [details] [review]
one issue....

There seem to be several issues, some of which I'm still getting to the bottom of.  But I figure we might as well nail 'em as I find them.

One issue is that we are examining every menu item until we find the selected one rather than querying the selection and asking for the selected child.  Where you will see an improvement with this patch is given a huge combo box (like one that contains all of the GNOME apps) where the selected item is pretty far down in the list (like Orca).  Here are the numbers for that case:

ncalls  tottime  percall  cumtime  percall 
    1    0.035    0.035    3.699    3.699 _getSpeechForComboBox old
    1    0.001    0.001    1.177    1.177 _getSpeechForComboBox new

    1    0.036    0.036    4.846    4.846 _getBrailleRegionsFor... old
    1    0.001    0.001    0.035    0.035 _getBrailleRegionsFor... new

Rather significant, I think.  However, when I used the attached patch and tabbed through the advanced bugzilla search page, I saw essentially no improvement whatsoever.  :-( In that case (and even in the case I just mentioned), we're spending a rather significant amount of time in default.py's locusOfFocusChanged() -- why remains to be seen.

Anyhoo, this patch is pylinted and functionally tested, but not regression tested yet.  I'll do that in a bit.  My brain is still in "hunt down the problems" mode. ;-)

Mike mind testing this a bit in the meantime and letting me know what you find?

The slowness I'm seeing on the Advanced Search page is not combo boxes.   I just made a test case with an enormous combo box and an entry on its right and one beneath it.  We were quite speedy tabbing among those items.  

What seems to be going on is this:

1. Our very own bugzilla suffers from some label bogusity so first we get the label and then do some checking only to discover it's no good.

2. Depending on the form, we then try guessing from the line (and often don't find a candidate label).  Then we try guessing from the table (and often don't find a candidate label).  And then we look to other lines (and sometimes fail to find a candidate there as well).  Label guess is not an inexpensive endeavor.  Mind you I have some ideas; one I'll try now and one which is more longer-term -- but both of those are not this bug. :-)

I believe I have found a major culprit of sluggishness w.r.t. combo boxes and I'm not seeing any other combo-box specific issues.  Mike please test this patch on its own merits.  Thanks!

This does seem to make an improvement I'd say if the regression tests check out it looks good to me.  

Regression tests check out.  Moving to pending.  Hopefully this plus the other performance bug/patch I filed this afternoon will help.  I'll run numbers from the two combined in a bit.