New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Over time, NVDA lags with firefox open #3138

Closed
nvaccessAuto opened this Issue Apr 7, 2013 · 4 comments

Comments

Projects
None yet
2 participants
@nvaccessAuto

nvaccessAuto commented Apr 7, 2013

Reported by tspivey on 2013-04-07 16:21
If I leave firefox open for a long time (can be hours to days), NVDA starts to respond slowly. I notice while alt+tabbing and moving around lists in tween.
When I restart firefox, this stops for another few hours.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Apr 8, 2013

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.

nvaccessAuto commented Apr 8, 2013

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.

@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Apr 9, 2013

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.

nvaccessAuto commented Apr 9, 2013

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.
@nvaccessAuto

This comment has been minimized.

Show comment
Hide comment
@nvaccessAuto

nvaccessAuto Apr 21, 2013

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))

nvaccessAuto commented Apr 21, 2013

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))
@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Mar 29, 2017

Contributor

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.

Contributor

jcsteh commented Mar 29, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment