Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]



On Fri, 2005-06-10 at 09:47 -0400, Luis Villa wrote:
> On 6/10/05, Alexander Larsson <alexl redhat com> wrote:
> > On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote:
> > > On 6/10/05, Luis Villa <luis villa gmail com> wrote:
> > > > > > I haven't seen this announced on gtk-devel or here, so:
> > > > > >
> > > > > > http://gtkperf.sourceforge.net/
> > > > > >
> > > > > > Apparently this is a test tool to test gtk performance. Would be great
> > > > > > to have someone test 2.7 with it.
> > > > >
> > > > > Went ahead and did it myself. TextView is brutally slower (300-400%),
> > > > > some other things are 25-30% slower, and some things actually get
> > > > > faster. Disclaimer: I'm pretty sure I did this right and I'm linking
> > > > > against the right stuff, but these numbers should be confirmed by an
> > > > > expert, and I can't speak to the validity of the tool's measurements
> > > > > itself, except to note that scrolling in a textview area is *visibly*
> > > > > slower.
> > > >
> > > > New third column is HEAD + glitz, with an x31's ATI card.
> > >
> > > Someone larted me on IRC and informed me that it is likely that glitz
> > > wasn't actually being used. So take these with an even bigger grain of
> > > salt than my last set. I would love to know how one can (1) know for
> > > certain glitz is being used and/or (2) how to force glitz to be used
> > > so that I can do a quickie hack to automate this.
> > 
> > > > Total time: 253.31 565.94 647.60
> > 
> > The question is: Why did you get different times then?
> 
> Very good question. I tried to kill anything particularly
> CPU-consuming, and in all cases stopped using the machine during the
> test, so I don't *think* that is a factor, but it could have been-
> it's not like I was running this on a perfectly-controlled test box.
> (Which I'd like to do, as part of the tinderboxing, whenever someone
> gets me a box to tinder on  :)

I suspect that it's just difficulties in the benchmark ... especially 
with GtkTextView, things can happen a little differently each time you
run it ... a different balance between repainting the screen and 
updating the text. Everything other than GtkTextView looked the same
up to noise, but the GtkTextView numbers dominate the total.

Regards,
							Owen

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]