[Scummvm-devel] Slowdowns in SCI and SAGA

yotam barnoy yotambarnoy at gmail.com
Fri Nov 27 08:53:34 CET 2009


OK guys

I was in the process of creating another profiling file when, after
rebuilding with -DDISABLE_DOSBOX_OPL this time, I found that SQ3 is
running at a very good speed. That difference is probably due to the
fallback change that (I think) Johannes made or it may be due to my my
own incompetence previously :). Either way I'm a happy camper.  The
joy of beholding Conquests of Camelot on my PSP with its artwork the
way it was intended to be seen!

Thanks again for your help guys!

Yotam



On Thu, Nov 26, 2009 at 5:47 PM, Max Horn <max at quendi.de> wrote:
>
> 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
>




More information about the Scummvm-devel mailing list