Hi,
On Tue, May 01, 2001 at 12:09:24AM -0700, Matt wrote:
> Using gprof (wouldn't used one of the other better ones, but none would
> build on Redhat 7.1 :( ) and Kprof, I did some analysis on the performance
> profiling output.
>
> A couple of places that optimization could help:
>
> _gfxr_auxbuf_spread (754 calls @ 6.7ms/call)
This one's a bit surprising (i.e. it's good you brought it up)- it is used
during picture drawing to get rid of some artifacts.
Improving it should be possible, although a bit risky, so this is not
something we should do until after the release.
> gfx_xlate_pixmap (283 calls @ 12.9ms/call)
While I'd be more than happy to accept patches to improve the pixmap
filters, I don't think that any significant improvements can be made here
(except maybe in the rarely-used 'linear' filter).
> _gfxwop_visual_draw (1189 calls @ 2.8ms/call)
This one does a full widget tree traveral and draws all changes. There is
little that can be done to improve it, I'm afraid.
> While investigating, I noticed that on gfx_resource.c around line 211
> SIZETYPE, FUNCNAME,etc are defined and then re-defined around line 221.
> Is this supposed to be happening? It looks like an ifdef/endif pair is
> missing.
No, this is perfectly fine. They're #undef'd in the file included
(consider them macro parameters); we essentially create four separate
functions for each of the supported color depths, times three for the
number of supported pixmap filters.
> To reproduce my results, go get kprof (http://kprof.sourceforge.net, needs
> KDE and qt installed).
Thanks, but this stuff is C++, which essentially means I'd have to compile Qt,
the KDE base libraries and everything else kprof needs by hand (using Compaq's
cxx compiler), since the versions shipped in Debian are built with gcc and,
therefore, don't work.
I've installed it on my IA32 box, though (remote displaying will probably alter
the results somewhat).
Thanks!
llap,
Christoph
