bbbradsmith/nsfplay

Debug performance is poor

bbbradsmith opened this issue · 2 comments

The debug build of NSFPlay is known to have relatively poor performance. I received an e-mail with some compilation tips that may help:

I managed to reach decent performance of debug build without any changes in code. Main reasons of poor performance are STL (surprisingly) and of course general debug overhead. So maybe future version could use some simple containers instead of STL containers (particularly std::vector) in classes of xgm namespace. What i tried:

https://stackoverflow.com/questions/3362895/visual-studio-application-running-extremely-slow-with-debug
    Changed /ZI to /Zi compilation flag (big difference!)
    Changed _DEBUG to NDEBUG (not sure about it)
    Applied "Enable Windows debug heap allocator (Native only)" option in visual studio (not sure about it)
https://stackoverflow.com/questions/15949582/drastic-performance-differences-debug-vs-release
    Applied "_HAS_ITERATOR_DEBUGGING=0" preprocessor definition to the project (big difference!)
Disabled some runtime checks (big difference!)
    Basic runtime checks: uninitualized variables
    Security check: disable security check

And voila - now it performs relatively good.

After an overhaul of the resampling code, a simpler solution here is just to turn the "quality" slider all the way down in the settings. Except for rare cases of sub-sample CPU vs APU/expansion synchronization this will make very little difference (other than output audio quality), so it should be pretty suitable for debugging.

With version 2.4, debug performance can be improved a lot by simply setting the quality slider all the way down.