On Tue, 15 Aug 2006 16:15:16 -0700, Carl Worth wrote: > > And if that "Resize" column is reliable and an accurate measure of > GTK+ performance in some sense, then it shows that GTK+ 2.10 is less > than 10% slower than GTK+ 2.6, (at least on my system---which is an > x86 box and obviously doesn't take any of the floating-point hit that > people have seen on embedded platforms). > > I'll run a few more tests today and post those so we can get a feel > for how stable these numbers are. I've got three new runs available now: http://cairographics.org/~cworth/gtk2.6_vs_2.10/20060815-2/ http://cairographics.org/~cworth/gtk2.6_vs_2.10/20060815-3/ http://cairographics.org/~cworth/gtk2.6_vs_2.10/20060815-4/ (The date stamps on these reports are for when I manually re-did the post-processing since the original processing failed on the new blank lines. The tests definitely did not complete in a matter of a few seconds.) As I suggested above, the "Resize" column does look fairly stable across these results, usually differing by only a few percentage points, and differing at most by 10% in the 3 tests above. The other columns show a lot more variation, however. For example, in the Boot column, the Clearlooks mean slowdown ranges from as bad as 1.57 to as good as 0.57. Similarly, in the Expose column, the Lighthouse Blue mean slowdown is 2.04 in the -2 run but only 1.46 in the -3 run. Drilling down into the results show the following anomalous timings for GtkFrame Lighthouse blue expose timings 2.6 2.10 GtkFrame-2 0.07 0.40 GtkFrame-3 0.38 0.09 http://cairographics.org/~cworth/gtk2.6_vs_2.10/20060815-2/LighthouseBlue/expose.html http://cairographics.org/~cworth/gtk2.6_vs_2.10/20060815-3/LighthouseBlue/expose.html So something very funny is happening there. I don't know where the non-determinism is coming from, but a result like the above makes the "Expose" numbers seem very un-useful. But so far I haven't found evidence that GTK+ 2.10 is dramatically slower than GTK+ 2.6---at least on typical desktop hardware[*]. (Though it definitely does appear to be a bit slower in general, and rarely faster). These conclusions are based on the Resize columns in the above results. That the newer versions of GTK+ aren't a lot slower when drawing the same things is good. But it's not helpful for my current goal which is to find things which should be made faster in cairo. So for that I'm planning on not looking in the above cases much more myself. There aren't any obviously bad problems here. But I know we can find some terribly slow stuff where cairo is being used more actively by themes and applications, so I'll start doing more work in that area. -Carl [*] And yes, previous results posted here do show more dramatic slowdowns for newer versions of GTK+ on embedded systems. And I'm glad people are now looking into fixes for some of the problems identified there, such as heavy reliance on floating-point. -- cworth redhat com
Attachment:
pgpqQFwDZdY8N.pgp
Description: PGP signature