GNOME Bugzilla – Bug 118657
Drastic slowdown in terminals when 'accessibility' key in gconf on
Last modified: 2009-01-20 12:37:10 UTC
The essential summary is as per the subject: I am seeing a huge slowdown of most of Gnome and particularly gnome- terminals after toggling an accessibility key in gconf. I do not know how to measure it. This is just 'how it feels'. Yesterday: Gnome on RH 9+distro security updates. So "Gnome 2.2", basically. Someone wanted me to try something with Dasher. For that, I needed to toggle a GConf key first. Did that, restarted Gnome, did the stuff that started all this.. and did not restart Gnome. Thought I'd leave a11y on in case I needed it again. The last bit of ~/.gconf/desktop/gnome/interface/%gconf.xml: <entry name="accessibility" mtime="1059518265" muser="hobbit" type="bool" value="true"/></gconf> This morning, as I type away in zillions of gnome-terminals, I am finding text takes ages to show up, scrolling is slow, and even light-weight text editors are having to catch up once I stop typing. I do not now have any ATs running. Suggestion on #gnome is that this is because terminals and accessibility are hard, and that I should file this against at-spi. I don't know how to get real numbers. Suggestions welcome :) Oh yes. On 'top', if I sort by 'T' to sort by time used, at-spi-regist (and then it cuts off at the end of the screen) is up at position number 5. This machine has been up for a couple of months, so it doesn't surprise me to see two kernel daemons are high in the total time used. Seeing X (restarted last night) isn't that surprising. But seeing gnome-terminal (ditto) and at-spi (started for the first time last night) does. Should it? (I don't even know if it's relevant, just included in case it is.) PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 7 root 15 0 0 0 0 SW 0.5 0.0 138:35 0 kscand/Normal 6583 hobbit 15 0 20116 19M 5932 R 24.2 3.9 19:43 0 gnome-termina 6528 root 15 0 175M 15M 1988 S 5.6 3.1 6:42 0 X 26 root 15 0 0 0 0 SW 0.0 0.0 2:59 0 kjournald 6563 hobbit 15 0 2572 2572 1876 S 1.9 0.5 1:36 0 at-spi-regist Sorry for the nebulous nature of this report. Basically: is this huge (to me) hit in gnome generally and gnome-terminals in particular known, is this expected, is it a bug, is there a way to find out what's happening? If this is all known (I did search bugzilla first), sorry, and feel free to close it. I know very little about accessibility and don't know whether this is a concern.
hi telsa; well said. This is sort of expected but I don't think it's something we think can't be improved. Current thinking is that part of the problem has to do with vte and how it handles at-spi events - things seemed to be much much faster with zvt (but not bug free). I think we'll be whittling away at this over time. Right now, while not totally ignoring performance, we are taking the view that functionality comes first at least when the 'accessibility' key is turned on, and that performance issues are an annoyance that can be tolerated by the target audience in the short term. That said, I expect there are leaks, etc. in the vte/accessibility code or in the way it's used by gnopernicus, etc., and there is bound to be some low-hanging fruit for those armed with profilers. - Bill
adding accessibility keyword
Hi there I had a "similar" experience with gnopernicus enabled (and gnome-speech enabled) this seemed to hang or at least slow down my system VERY much which will not be acceptable even to the target audience (at least once gnome speech is implemented it would block playback of the speech and cause jibberish from the speakers in the end render gnomespeech useless :)
Erling: gnome-speech is implemented already, so I do not understand your comments. It sounds as though what you experienced may _not_ be the subject of this bug at all (which concerns only the result of setting the 'accessibility' gconf key to true, and has nothing to do with gnopernicus).
Suggest changing the Status Whiteboard (aka "accessibility priority") value. The sluggishness problems are so severe in active use with Gnopernicus that this should be considered a "candidate stopper".
peter: I don't have evidence of what you said. If you are seeing slowdowns this severe, it's a different bug from the majority of the discussion in this bug report. I am _not_ seeing performance problems of this magnitude. Perhaps you are being bitten by the "new Tab causes vte to do horrible things" bug? (127191) as I understand it, the tabs aren't really "freezing" but certain invocations of new terminal tabs seem to cause the resulting tab to have really, truly horrible performance problems. This is not the case for the "first" terminal tab.
100% reproducible case on my system: 1. Start Gnopernicus with Speech and BrailleMonitor 2. Open gnome-terminal 3. cd to ../j2sdk1.4.2/demo/jfc/Stylepad 4. `java -jar Stylepad.jar` 5. Tab through the Styelpad GUI a bunch. This will generate a lot of debug text output into the gnome-terminal with this build (Ireland 20Feb04 CVS build) 6. Exit the Stylepad demo via the GUI (e.g. F10, down arrow to Quit) 7. gnome-terminal is now VERY sluggish, often taking many seconds to respond to <CR>, and seeming to get slower and slower over time.
OK, but this is not the same bug that was initially filed for this report; this bug does not include the use of gnopernicus or gnome-speech. Have you checked the terminal's behavior without gnopernicus, or even without accessibility? There are known problems if lots of text gets scrolled to the terminal (i.e. to stderr or stdout; terminal can crash or hang then!) No bug report for that to my knowledge, however.
I haven't seen the same level of slowdown without Gnopernicus, though I have seen occasional sluggishness. If I get a reproducible case I'll annotate this bug. Meanwhile of note: with Gnopernicus, things got so slow toward the end of my playing with it today (after annotating this report above) that it was multiple minutes before gnome-terminal would respond.
that (slow with gnopernicus) sounds like a bug which might be more appropriately filed against gnopernicus, at least initially.
I am opening a new bug against vte, "slow with gnopernicus", which is a different issue (the level of performance impact tolerable for the user groups is different, as is the observed performance). This bug is about performance impact when no AT is present, but the "enable at" option is TRUE.
new vte bug is #136448, "vte extremely sluggish with gnopernicus". It's not clear whether the problem's root cause is in vte, or gnopernicus' interactions with vte.
I'll just update this for updating's sake: I am not currently using any AT, from gnopernicus to Dasher to whatever else might use it. I do still have that accessibility key switched on. (Just because I haven't restarted in a while.) I am seeing the same problems in Fedora Core 1 with Gnome 2.4. Particularly noticeable using terminals with 70+ lines (not maximised, just lots of lines) and epic, lynx, and man/less. I get the problems of the first line being endlessly repeated for several seconds when I hit 'b' in less (should scroll back a page). Again, other than picking a set sequence of commands and buying a stopwatch and posting "it takes this many seconds to update the screen" (and really, it is seconds, for just plain text: Mozilla is now faster than Lynx for me!), what applications or profilers can I aim at this and what results would help anyone who is looking at fixing it?
well Telsa, I hate to do this to you but... :-) if you rebuild ORBit2 with --enable-debug, then set ORBIT2_DEBUG=traces in your environment, you will get lots of horrible spew when running gnome-terminal in an xterm (weird I know; kill all gnome-terminals then run an xterm and run "gnome-terminal" there). The horrible spew will reveal all the info which the terminal is sending to at-spi-registryd, and we can try to see if it is indeed excessive. Note however that ncurses apps like lynx, etc. are liable to be inherently horrible in this context, as every screen redraw MUST be reported to at-spi as multiple line text changes.
Just to keep this open: I haven't forgotten. I am about to upgrade from Fedora Core 1 (and Gnome 2.4) to Fedora Core 2 (and Gnome 2.6), at which stage I shall rebuild ORBit2 with said flags and investigate. Doesn't seem much point in doing it with Gnome 2.4 right now, since as I write the "Proposed: for Gnome 2.7/Gnome 2.8" emails are starting. Just rebuild ORBit2? Nothing else? (Now is a splendid time to tell me about anything else). I begin to understand what you mean about ncurses apps, incidentally. I restarted X. After a day or two I had recourse to Lynx and suddenly my ogg- playing (ogg123, nothing fancy :)) was skipping, my terminals were taking an age to redraw and so on. They were fine until I started Lynx. No reason why I can't update the Version, btw, is there?
Nope, other than the fact that sometimes leaving it at "2.1" lets us know that the problem has been around awhile. By they way, you might want to redirect the ORBit traces to a file - the mere act of writing them to xterm is liable to slow you down a lot. But it will help identify what notifications are happenning when the terminal is being used. I think we've decided that ncurses support is basically not recommended; if you must use ncurses, you might want to turn off assistive technology support temporarily. I suppose that long-term, we ought to provide some gconf key so that when ncurses is being used, terminals temporarily stop reporting events, or report them in a more chunky way (i.e. every now and then emit a single "I've changed" event). A screenreader user probably would have to resort to periodically re-reading the whole window, line-by-line, when ncurses is being used. Yuck. Another reason why "use console apps" isn't a panacea for blind user access to applications.
modifying summary since "drastic slowdown" is not visible in anything but terminals, and even then there's some debate about it.
I'm not debating it. It's happening on Gnome 2.6 from Fedora Core 2 now. I've pretty much abandoned Lynx, but it is still very noticeable in vim. Now I have Gnome 2.6 and 2.7 available, I shall rebuild ORBit as per comment 14 and see what I get.
Any update, Telsa?
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
Telsa, is this still a problem with latest vte/gnome-terminal and latest GNOME?
You know, it's so long since I messed about with this, I have forgotten how to toggle the accessibility on and off! I'll give it a go when I get a spare hour or two (which means in a couple of days, probably. Sorry - life went busy :))
No problem. The bug has been festering for 4 1/2 years, a few more days won't matter. ;-) I'm not sure what system you are using, but on my Ubuntu system, the magic doohickey can be found under: System->Preferences->Universal Access->Assistive Technology Preferences There is a checkbox there labeled "Enable assistive technologies". Check that, and hit Close. I think you might need to log out and log back in again. Thanks.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
I can confirm that on my Debian Lenny box, gnome-terminal goes rather fast now.