Hi,
On Tue, 5 Jun 2001, Matt wrote:
> As I mentioned on IRC, I re-ran a profiling tool. The MCI midiOut* calls
> only account for about 3% of the total cycles. Some higher ones include:
> gfxr_auxbuf_spread looks like a good candidate for optimization.
> gfx_crossblit_16_P does a *lot* of memcpy's. Someone might want to look at
> that as well.
This counted cycles in all threads? In this case, midiOut* used a _very_
substantial amount of time. Can your tool do per-thread profiling? The
functions you mentioned are not related to the sound thread.
gfxr_auxbuf_spread(), as mentioned, is a rather complex beast which really
could use some optimization. However, even minor functional changes might
completely break many background pictures, so this has to be done with
great care and constant testing, not exactly a quick one-evening hack.
gfx_crossblit_<colordepth>[_P] are the various crossblitting functions for
the default crossblitter (for graphics drivers which don't have built-in
blitting support, i.e. all of them).
They use memcpy() to transfer single pixels, assuming that this takes care
of any alignment problems. Since all C compilers I've used so far appear
to inline fixed-size memcpy(), this should, at worst, give the same
performance as using platform-dependant alignment-checking assignments to
transfer the various values without all the bugs caused by this, and, at
best, allow the compiler to understand the code much more easily and
optimize it appropriately.
Yes, this will suck if memcpy() isn't inlined.
> While I was playing around in Quantify looking at this stuff, I made a
> neat looking callgraph that illustrates sort of how FreeSCI is organized.
> This might be helpful (or confusing) to new developers:
>
> http://www.lag.net/~matt/tmp/sci_callgraph_small.jpg
Looks interesting :->
> I know it doesn't have everything, but it was really hard to get
> everything to be reasonably small. Hope it's at least amusing to some
> people :)
I guess it'd make an interesting addition to our development page, if you
don't mind...?
llap,
Christoph
