Re: Performance of Gnome and Gnopernicus

["John J. Boyer" <director chpi org>]

Thomas,

When I posted the initial message of this thread, I was wondering if 
something might be causing excessibe disk thrashing. My machine is 400 MHZ 
with 320 MB of memory. I can't remember exactly wehat the video card is, 
but it a Blade card with at least 1024 by 768 resolution. Thge machine is 
about four years old.

John
 On Wed, 28 May 2003, Thomas D. Ward wrote:

> Well, for what it is worth I have a 1.2 GHZ system with 256 MB of ram, and
> gnopernicus and festival work vary well together on this system without
> allot of breakups or  lags.
> It might be instructive to know what hardware,  processor, and memory is
> being used by the machines that have this lag.
> 
> 
> 
> 
> ----- Original Message -----
> From: Bill Haneman <bill haneman sun com>
> To: Michael Meeks <michael ximian com>
> Cc: Adam Myrow <amyrow midsouth rr com>;
> <gnome-accessibility-list gnome org>
> Sent: Wednesday, May 28, 2003 7:24 AM
> Subject: Re: Performance of Gnome and Gnopernicus
> 
> 
> > Michael/All:
> >
> > Note that the blocking while delivering events to clients is, in fact, a
> > feature and not a bug.  That is to say, if we don't block at that point
> > it can create more problem than it solves for assistive technologies.
> > Better to block until the notifications have gone out.
> >
> > This doesn't at all explain a two-second delay however.  My benchmarks
> > have indicated that on modest machines we can process a few thousand
> > AT-SPI calls per second.  The maximum latencies in this part of the
> > process are really quite small from the "user time" perspective.  I
> > think that the visible lags are coming from the way the APIs are being
> > used, etc.
> >
> > regards
> >
> > Bill
> >
> > On Wed, 2003-05-28 at 11:37, Michael Meeks wrote:
> > > Hi Adam / John,
> > >
> > > On Tue, 2003-05-27 at 04:42, Adam Myrow wrote:
> > > > I would like to know this as well. I hate to say it, but as pleased as
> I
> > > > am that Gnopernicus does something, I have to say that Gnome strikes
> me as
> > > > a very bloated, slow desktop.
> > >
> > > For what it's worth - the problem is in fact not Gnome, but the latency
> > > inherent in the event emission mechanism that is used; we can speed it
> > > up very substantially with relative ease;
> > >
> > > >  It also depends on what speech driver you are using.
> > >
> > > This is prolly an architectural issue in gnopernicus / gnome-speech.
> > > Someone needs to sit down with a debugging ORBit2 and
> > > ORBIT2_DEBUG=traces:timestamps - and see what's going on.
> > >
> > > One of the problem is that per event, the application hangs until the
> > > registry has emitted the events to each AT (serially, blocking until
> > > each has finished processing the event).
> > >
> > > Another thing would be to do asynchronous unrefs / more aggressive
> > > caching; can you try doing a tweak for me and seeing if it helps ?
> > >
> > > If you hack at-spi/cspi/spi_main.c (cspi_object_unref): and just #ifdef
> > > out the body of the method - that may save a number of round-trips, at
> > > the cost of some leakage at the client; it'd be interesting if that
> > > makes a noticable difference.
> > >
> > > Regards,
> > >
> > > Michael.
> > >
> > > --
> > >  michael ximian com  <><, Pseudo Engineer, itinerant idiot
> > >
> > > _______________________________________________
> > > gnome-accessibility-list mailing list
> > > gnome-accessibility-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> >
> >
> > _______________________________________________
> > gnome-accessibility-list mailing list
> > gnome-accessibility-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> 
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
> 

-- 
Computers to Help People, Inc.
http://www.chpi.org
825 East Johnson; Madison, WI 53703