Re: Performance of many widgets



Thanks very much for looking at this John

I didn't get nearly that dramatic of a speedup, maybe 2x.  I get about
this same result on a 1Ghz Via machine w/ openchrome on cx700 (2x
speedup)

The funny thing is, using event boxes with pixmaps like the javascript
uses also results in a fairly slow update.  Maybe I am loading the
pixmaps incorrectly or something.  There has to be a way to optimize
this since there is no rendering.

I'll send you example code doing this in a later update.

I think there is room for some optimization here considering firefox
does the same thing but faster.

Here are my stats for 10 clicks in Redmond
$ time ./main

real	0m4.739s
user	0m0.700s
sys	0m0.070s

Here are my stats for 10 clicks in Ambiance
$ time ./main

real	0m11.299s
user	0m1.420s
sys	0m0.130s

Its funny that it says 1.42 seconds, but I wait until the screen is
updated before I click (~0.4 seconds).  I have an Intel Core 2 duo and
Intel Graphics card.

It may be a 10x speedup in actuality because it takes a long time for
the gui to actually update and time may be wrong or I am interpreting
it wrong.

Here is my oprofile results:

$opreport -a -l -g
CPU: Core 2, speed 1200 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a
unit mask of 0x00 (Unhalted core cycles) count 100000
samples  cum. samples  %        cum. %     linenr info
image name               app name                 symbol name
21814    21814         15.1615  15.1615    (no location information)
libc-2.11.1.so           libc-2.11.1.so           /lib/libc-2.11.1.so
19012    40826         13.2140  28.3754    (no location information)
libpixman-1.so.0.16.4    libpixman-1.so.0.16.4
/usr/lib/libpixman-1.so.0.16.4
17866    58692         12.4175  40.7929    (no location information)
libcairo.so.2.10800.10   libcairo.so.2.10800.10
/usr/lib/libcairo.so.2.10800.10
12673    71365          8.8082  49.6011    (no location information)
libglib-2.0.so.0.2400.1  libglib-2.0.so.0.2400.1
/lib/libglib-2.0.so.0.2400.1
9810     81175          6.8183  56.4193    (no location information)
Xorg                     Xorg                     /usr/bin/Xorg


On Mon, Jan 3, 2011 at 6:01 PM,  <jcupitt gmail com> wrote:
> On 3 January 2011 21:51, Brian Phelps <lm317t gmail com> wrote:
>> I tried the plain default theme BTW and it made no discernable
>> difference in speed to the GTK/C implementation.
>
> I tried here and on a Ubuntu 10.10 install on a recent macbook with
> the Ambiance theme your example was rather slow. There was an
> appreciable delay (0.5s? something like that) between pressing the
> top-left button and the display updating.
>
> I tried running under callgrind and it does seem to be spending a lot
> of time somewhere deep inside libcairo (the graphics library that gtk
> uses to draw the screen). I don't have a dbg version of cairo handy to
> dig deeper.
>
> If I run with "time" and press the toggle button 10 times, I get:
>
> $ time ./main
> real    0m18.022s
> user    0m5.040s
> sys     0m0.300s
>
> I installed the gnome-themes-extra package, plus a thing called
> gtk-theme-switch, and swapped to the "redmond" theme. This is just
> hideous (a win95 lookalike) but does use very simple drawing
> operations to display the widgets. With the redmond theme, display
> updates are instant (or seem to be).
>
> For 10 button presses I get:
>
> $ time ./main
> real    0m13.190s
> user    0m0.360s
> sys     0m0.060s
>
> So, more than 10 times faster. Brian, have you tried a simple theme
> like this (ugly square buttons, no gradients)?
>
> Comparing a browser to gtk is perhaps a little unfair. This test is
> spending almost all its time in the graphics library, not in gtk, so
> you are really comparing the speed at which a browser can display
> bitmaps (rather fast) to the speed libcairo can draw gradients and
> anti-aliased curved lines (comparatively rather slow).
>
> Though it does seem sluggish, even so. Perhaps there are some simple
> changes that could be made to togglebutton, Ambiance or cairo to speed
> it up. I don't have time to investigate, sadly :-(
>
> John
>


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