Comment 1 by briang1 on 2013-04-08 07:07
Well the problem I find that causes this is dependent on which update channel you are on. since the increase in betas etc, I've found that while its downloading in the background then Firefox can get very sluggish, but as a restart installs the new code it speeds up again. Is this what you are seeing? You can test if its downloading by going to help, about and moving to the very top where it will tell you the version and any activity like downloading update or installing update.

Comment 2 by jteh on 2013-04-09 07:03
Quick technical notes:

• Probably caused by treeInterceptorHandler.cleanup, which is called for every focus change. isAlive does cross-process calls and this is O(n) based on the number of buffers. It might also respond slowly if the application is busy.
• If we can, it'd be ideal to not call cleanup on every focus change and instead do it when the user is idle or similar.
• This needs to be considered carefully, as it might break things; we don't want new objects being associated with the wrong buffers, etc. In particular, consider 6874631.

Comment 4 by tspivey on 2013-04-21 06:15
I haven't been tracking this all that frequently, but it usually takes around 30-40 MS to call cleanup.
I notice this. Not all the time, but enough to where I don't want to have a lot of tabs open, because it negatively impacts the rest of my system.
In firefox, it seems to take around 3 ms per tab. I'm testing this by creating new tabs at my homepage, which is about:blank.

Timing script:

    def script_test(self, gesture):
        total=0
        for i in xrange(10):
            t1=time.time()
            treeInterceptorHandler.cleanup()
            t2 = (time.time()-t1)*1000
            total += t2
        ui.message("%d" % (total/10))

We can probably improve this significantly by cleaning up the isAlive property on the gecko_ia2 vbuf. Right now, it calls NVDAObjects.IAccessible.getNVDAObjectFromEvent, which is a complete waste. As a minimum, we could just check for the defunct state. Even calling accChild directly would be better than calling NVDAObjectFromEvent.

P2 because this can make NVDA sluggish for users with a lot of tabs.