Week 37/2012: Tuning and optimizations
Last week we were investigating performance bottlenecks. I also fixed a couple of bugs and then caught a cold, which prevented me from doing much rational thinking for a few days.
Recently both DaniJ and I have been investigating performance bottlenecks. During the development of the 1.9 series the renderer has undergone significant refactoring, but it has come at a cost: some of the subroutines and data structures used when rendering are not optimized for fast performance. One reason for this is that the majority of this work was done before we switched to C++, and thus it was much harder to deploy the appropriate, efficient algorithms and data structures. In other words, we've done some lazy programming with the intent of optimizing at a later point in time.
The two focus areas for optimization have been map loading and rendering of the player view during gameplay. When it comes to map loading, DaniJ has been putting a lot of effort into refactoring the BSP builder and optimizing its performance. At least I've seen some significant improvements in map loading times thanks to this work.
I've been profiling the engine's performance and have located a few specific areas in need of improvement. For instance, map rendering seems to be suffering from two bottlenecks. The first is an underperforming data structure called GridMap that is used, e.g., for tracking luminous objects visible in the frame. DaniJ is presently revising this code for improved performance; perhaps he will elaborate on the status and details of this later on. The second bottleneck is in subsector visibility checking: when the BSP tree is traversed during rendering, each and every subsector's all segments are separately checked for visibility before it can be determined if the subsector might be visible. While this is perfectly fine in closed spaces, in large complex open areas the renderer does a lot of checking that ultimately is pointless, because in an open area visibility occlusion is unlikely to occur regardless of camera position. We have a couple of ideas for addressing this, but as a non-trivial task it will in all likelihood be postponed to a later release (post 1.9.9).
I did a minor optimization related to a math routine used commonly during rendering. You may see a small (few percent max) improvement in frame rates.
Other changes:
Recently both DaniJ and I have been investigating performance bottlenecks. During the development of the 1.9 series the renderer has undergone significant refactoring, but it has come at a cost: some of the subroutines and data structures used when rendering are not optimized for fast performance. One reason for this is that the majority of this work was done before we switched to C++, and thus it was much harder to deploy the appropriate, efficient algorithms and data structures. In other words, we've done some lazy programming with the intent of optimizing at a later point in time.
The two focus areas for optimization have been map loading and rendering of the player view during gameplay. When it comes to map loading, DaniJ has been putting a lot of effort into refactoring the BSP builder and optimizing its performance. At least I've seen some significant improvements in map loading times thanks to this work.
I've been profiling the engine's performance and have located a few specific areas in need of improvement. For instance, map rendering seems to be suffering from two bottlenecks. The first is an underperforming data structure called GridMap that is used, e.g., for tracking luminous objects visible in the frame. DaniJ is presently revising this code for improved performance; perhaps he will elaborate on the status and details of this later on. The second bottleneck is in subsector visibility checking: when the BSP tree is traversed during rendering, each and every subsector's all segments are separately checked for visibility before it can be determined if the subsector might be visible. While this is perfectly fine in closed spaces, in large complex open areas the renderer does a lot of checking that ultimately is pointless, because in an open area visibility occlusion is unlikely to occur regardless of camera position. We have a couple of ideas for addressing this, but as a non-trivial task it will in all likelihood be postponed to a later release (post 1.9.9).
I did a minor optimization related to a math routine used commonly during rendering. You may see a small (few percent max) improvement in frame rates.
Other changes:
- If you are playing a map when you start the installation of an update, you will be prompted to save the game.
- The Doomsday.out log will now always include the full command line used to start Doomsday. This should make tech support requests easier to respond to, as we can right away see which options were used to start the game. Previously this information was only included when the "verbose messages" option was being used.
- Fixed bug 1080: looking for plugins on some variants of Unix.