On Wed, 6 Jun 2001, Christoph Reichenbach wrote:
> > 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.
I believe it's across all threads, I'll have to look. I can do per-thread
profiling by calling Quantify's API from within the program, I'll do that
next time I start hcking on this.
> > 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...?
Nope, go for it. Maybe next time I'll make a similar image that focuses on
the VM or gfx subsystem.
--
http://www.clock.org/~matt
