I’ve spent the past couple of weeks experimenting with an iOS port of Doomsday. This is now at a proof-of-concept level and not playable yet. It isn’t quite the right time to continue much further along this path, but read on for my findings!
Tag: performance
Memory savings and metadata cache
Build 2237 introduces a number of changes aimed at making Doomsday launch faster and use less memory overall. It also fixes a couple of threading issues that were found with the help of Thread Sanitizer.
As part of preparing the stable 2.0 release, I’ve been looking at performance and memory optimizations.
Trimming memory use
I examined memory use in Instruments on macOS and identified a number of places for savings:
- There is now a purpose-built class for keeping track of observer relationships between objects. There are hundreds of thousands of these being used in the engine, so using a class that is more optimal for the task saves both memory and improves performance.
- Some objects had a lot of observers (20,000+) but worst of all, this was completely unnecessary because the observers were never being notified. These cases have now been removed.
- Reduced memory used by Doomsday Script bindings for file system access by removing several unnecessary variables and replacing them with callable functions. This saves memory because functions can be stored in the class objects rather than in the objects themselves.
- The file system caches uncompressed ZIP file contents in memory to avoid repeatedly decompressing them when the ZIP is being accessed. However, these cached contents were never released. Now ZIP caches are freed from memory whenever you return back to the Home screen.
After all these changes, Doomsday’s memory use on my system was roughly halved (from 830 MB to 460 MB). In practice, though, this heavily depends on how many resource packs and other data files you have available.
Caching metadata
When Doomsday is starting up it indexes and quickly analyzes all the resource packs, add-ons and other data files that you may have available. This may take a while depending on the number of these files and how fast your hard drive is. Starting with build 2237, Doomsday is now able to cache this information for future use, so after the analysis has been done it doesn’t have to repeated until the files change or new ones are added. Continue reading Memory savings and metadata cache
Tightening all the screws
For the past week I have been exclusively focusing on optimizations.
Work in the 2.0 unstable builds has been progressing without much attention having been paid to performance profiling. However, it has become clear that even in very basic maps (like Doom E1M1) there were unacceptable FPS dips. I decided to get to the bottom of what was going on. Continue reading Tightening all the screws
Simpler GL
Yesterday I merged all my recent work into the master branch, totaling about a month’s worth of new code. The changes largely focus on simplifying the low-level OpenGL classes. Continue reading Simpler GL
Game controllers, OpenGL cleanup
Recently I’ve been checking out game controllers (in a limited fashion), UI rendering performance (not great), and low-level OpenGL API usage (porting to Qt 5). Continue reading Game controllers, OpenGL cleanup