With what I think are source from git trunk (I'm a CVS/SVN guy getting used to GIT), I'm seeing that accerciser is consuming an entire CPU on my quad core machine.
Here's what I've done:
1) ./autogen.sh --prefix=`pwd`/bld --enable-xevie=no; make; make install
2) From three different shells sitting in my at-spi2-core directory:
b) gcalctool --gtk-module=`pwd`/bld/lib/gtk-2.0/modules/libspiatk.so
c) PYTHONPATH=`pwd`/bld/lib/python2.4/site-packages accerciser
The result is that accerciser is usable, but is consumes a lot of CPU:
PID USERNAME NLWP PRI NICE SIZE RES STATE TIME CPU COMMAND
1088 wwalker 1 10 0 160M 40M cpu/3 0:12 24.29% isapython2.4
I haven't done any triaging past this yet, but I will probably try running accerciser with the profile or cProfile module to see if that can tell me where it is spending its time.
In looking at the output of the 'profile' module, this seems like it might be an accerciser problem. What I noticed was that a lot of time was spent pumping events, but very little time was spent elsewhere:
ncalls tottime percall cumtime percall filename:lineno(function)
799338 2.740 0.000 3.820 0.000 /usr/lib/python2.4/site-packages/a
799338 1.080 0.000 1.080 0.000 /export/home/wwalker/Downloads/at-
In digging into the accerciser code, it looks like it's not really pumping any events, but is instead just throttling on the gidle thread. The suspicious method is _pumpEvents accerciser.py:
Runs the app.
# Tell user if desktop accessibility is disabled.
Even if there are no events to pump, the gidle thread is going to call accerciser's _pumpEvents method which is going to happily say "sure thing, call me again and again and again."
The odd thing, however, is that I don't see this when running accerciser with the AT-SPI/CORBA implementation. I'm not sure I understand why.