[Scummvm-devel] Slowdowns in SCI and SAGA

[Max Horn]

Am 26.11.2009 um 13:38 schrieb yotam barnoy:

> >>so 48.69 + 15.21 = 63.9 % for code clearly associated to the OPL  
> emulation. Hmm... still this list is somewhat surprising to me. For  
> example, why does it list CLIP<int> ? The profiler shouldn't  
> >>really be seeing this template, it should be fully inlined. What  
> optimization level do you use?
>
> Good call. I use -O0 optimization when profiling. I'm kind of new to  
> it, and thought it was important to keep minimal optimization like  
> in debugging. I could redo it with -O3 (our usual optimization), but  
> just assume that instead of the time being spent on CLIP, it'll be  
> in the calling procedure ie. CALC_CH.

Well, compiling with -O0, and running with profiling one, will  
definitely skew the results tremendously. Because it will make things  
a lot slower; thus sample generation (by the OPL emulator) is a lot  
slower; thus lock contention becomes a much bigger problem, because  
code will hold the lock a lot longer, etc.



>
> >>But the real bummer seems to be the 12.83% time spent in   
> OSystem_PSP::unlockMutex. I wonder if that's the mixer mutex, and  
> it's stalling because of lock contention.
>
> Here's the detailing of where that 12% goes:
>
>                 0.00    0.67     935/9608         
> DefaultTimerManager::handler() [54]
>                 0.01    5.87    8188/9608         
> Sci::SfxPlayer::player_timer_callback(void*) [18]
> [12]    12.9    0.02    6.89    9608          
> Common::StackLock::~StackLock() [12]
>                 0.02    6.87    9608/9608         
> Common::StackLock::unlock() [13]
>
> player_timer_callback is stalling on the lock.

Hm, odd. It should only stall on it when something else is holding the  
lock. From a quick test in SQ3, this is very rarely the case. Can you  
please tell us with which game you obtained these numbers?

Bye,
Max