performance regression or not?

Hi,

please consider the following WINEDEBUG=+fps numbers.
1.1.24              24-19 fps, depending on orientation
1.3.16              14-7 fps
1.3.18-291-g9da9240 14-6 fps
1.3.18-342-gab199f5 13-5 fps
1.3.19-46-g3025f7f   8   fps
1.3.20               7-4 fps
The low fps results in jerky character movement.

This looks like a serious performance degradation over time, isn't it?
Actually, the situation is much subtler and so confusing that I don't
know what to think about it.

- Disabling audio in winecfg yields 25 fps.  Audio seems to play a
  major role, although both CPU% of the dual core machine are mostly
  near 33%.

- Once and only once, while running 1.3.19-27-gf912e55, I observed 25
  fps (with sound!) instead of 13.  So new Wine *can* still play fast,
  it just almost never does it.  Why?

- After much bisecting, I've learnt that while newer versions of Wine
  typically produce low fps initially, I can go to the app's options ->
  graphics -> effects settings during game, change some of them, revert
  them to their original values, then observe 25 fps -- with sound!
  What's this weird relationship between sound and 3D?

- git bisect lead to a change about mmdevapi.dll that the app does not
  even use.  My hypothesis so far is that Wine or the app seems
  extremely sensitive to the random location of some stuff in memory.

- I don't believe the machine is overloaded. I can start 2 side by
  side, e.g. demo and retail, in different versions of Wine.

- I'm now wondering whether thread affinity may play a role.
  Alas, I don't know how to disable one core with Mac OS X 10.5.8

The app uses mono internally (windows' version).  It's named
2weistein  http://www.2weistein.de/  There exists a demo of the first 2
levels, but the level 'Lyrias Zauberbann' where fps varies much is
not part of the demo.

How to make sense of these observations?

Thanks for your help,
    Jörg Höhle
Testing using an "early 2009" NVidia Mac Mini with OS X 10.5.8 and XQuartz 2.6.1

[Stefan Dösinger]

On Monday 23 May 2011 19:13:10 [e-mail] wrote:
> This looks like a serious performance degradation over time, isn't it?
> Actually, the situation is much subtler and so confusing that I don't
> know what to think about it.

I'd say this is a performance regression in any case, although probably not a 
classic one where a function became slower. Considering that the CPU isn't 
fully utilized the application is probably waiting for something(e.g. a 
critical section) longer than it should. Even a slight change in an unrelated 
place might change that behavior. That could explain why disabling sound 
changes the behavior, or changing the settings(this often restarts the 3D 
renderer).

The strange bisect result could occur because the bug isn't always 
reproducible, so you entered git bisect good when you actually had bad code. 
It would be even nastier if the original code didn't always work and the game 
went from "works 80% of the time" to "works 20% of the time".

[Ken Thomases]

On May 23, 2011, at 12:13 PM,   wrote:
> - I'm now wondering whether thread affinity may play a role.
>
> Alas, I don't know how to disable one core with Mac OS X 10.5.8

Double-click on /Developer/Extras/PreferencePanes/Processor.prefPane.  That will install it to System Preferences.  Then, you can manipulate the processor cores.

Regards,
Ken