Have you used Rec Room on an older phone and found yourself thinking about checking social media while watching the progress bar slide across the screen? We find that frustrating, and I’m sure you do too! We know that Rec Room’s launch speed isn’t what most people expect from applications on their phone, especially on older devices. And mobile devices are an important platform, even more so with the recent Android launch. Plus, we realized that any wins for mobile would make login faster on all platforms. Everybody wins! To get players into the game as fast as we can, the platform team here at Rec Room set out at the beginning of May this year to understand what was taking so long and what we could do to speed things up.
Just How Much Faster Is It Now?
We used an iPhone 6s as a benchmark device to compare launch times. The 6s is an older model of phone, with less processing power and less memory available, and this makes it one of the slowest devices Rec Room runs on (and a great candidate for improvements). This video shows launching the app from the May 5th version of Rec Room side by side with a build including the performance improvements.
We tracked two primary blocks of time to measure progress:
How long does it take between launching the app and reaching the cached login screen, where the user can press the Play button?
How long does it take between pressing Play and the user loading into their dorm room?
The phone caches data on reloads to speed up relaunching, so we also measured cold start time (where the user has just turned on the phone and launches Rec Room for the first time) compared to warm start time (where the user has run Rec Room already, shut down the app, and then launched it again).
The improvements we made have less impact on newer devices. Faster hardware means that we spend less time blocked by the CPU, GPU, and disk speed of the device, and much more time waiting on network operations, like logging in to the player’s account and joining the player’s room. Because the most substantial improvements we made were reductions to CPU and GPU usage, the overall time savings is less of a fraction of the total time on faster hardware.
Approach to Performance Investigation and Iteration
If you’re trying to get to a friend’s house for their birthday, there are a lot of factors that might add extra time to your trip. You might take a longer route (thus driving farther than you need), or you might encounter traffic (slowing you down), or you might need to make a stop for gas (adding extra time to the trip). If you really need to get to your friend’s house faster, you might make some decisions to help. You might choose a shorter route, or you might carpool with a friend to be able to use a carpool lane to avoid traffic congestion, or you might fill up on gas in advance so that you don’t need to stop on the way.
There are similar issues and solutions for improving application performance. First, let’s take a look at the types of resources Rec Room needs to use when starting a game.
Disk usage. Loading game code and assets from the device’s hard disk storage into memory.
CPU usage. Running one or more threads that process game loading logic on the device’s CPU.
GPU usage. Copying textures, shaders, and other resources to the device’s video memory.
Network usage. Sending and receiving network messages to log the user in, fetch information about the user and the game, join the user’s initial room, and establish a voice connection.
A single task in Rec Room’s launch sequence might need to use one or many of these resources to successfully complete and then unblock other tasks to start. For example, a network operation needs to contact the server to find out what the player’s starting room is before the scene for that room can be loaded.
We initially started our performance investigation by categorizing which tasks run during launch and how long each one takes. We added custom time blocks in Rec Room that wrote out operation names with their start and end times and then generated a chart summarizing the results. This was helpful for two reasons:
We could pick the longest tasks and then take a deeper look to find out if it was necessary for those tasks to take that long.
We could look at the overall sequence of tasks to see if some could perhaps be completed earlier or at the same time.
Visual summary of time spent during boot
To get a deeper understanding of why a task takes the time it does, we used Unity performance tools and Apple’s Instruments to get a deep understanding of how time is spent. Unity’s tools help understand how much CPU time is spent each frame, and where that time is spent but doesn’t give as much insight into the parts of app startup that occur before Unity loads. Instruments give more information about the pre-Unity startup time, and also allows for detecting blocked time and time spent on background threads. We added the same type of time tracking to Instruments that we had in the summary chart, which helped us then directly understand what code was running during those blocks.
Tracking time spent during the launch sequence in Instruments
Here are a few examples of performance gains we were able to make with this knowledge:
A few third-party libraries were initializing features that Rec Room does not use. One of these involved compiling and uploading compute shaders for advanced rendering features, and we could remove those compute shaders entirely to save GPU utilization that ultimately blocked the main loading thread for many seconds.
Some of the content loaded before the user logs in could actually be deferred until after the user logs in. This allowed us to shorten the amount of time before the user can interact with the login UI.
Some tasks that require a network result could start earlier if we guess correctly that the result has not changed since the last session. If it turns out those infrequently-changing values are different, then we have to backtrack and redo work, but in almost all cases we can instead benefit from the result not changing by having already finished the work by the time the server confirms that the values are identical!
Some network operations (like initiating joining the dorm room) could be done at the same time as operations that require CPU and GPU usage (like loading the scene for the dorm room). By overlapping these operations, the total time spent waiting is reduced.
Conclusion
We know that reducing startup time is important: everyone wants to be able to play Rec Room as fast as possible after launching. We were able to make startup 45% faster on low-end iPhones and 23% faster on high-end iPhones by removing some unused functionality and by changing the required functionality to happen faster or in parallel. We’re excited about the time reduction we’ve been able to make so far, and we’re going to continue looking at more ways to reduce the startup time even more. We hope players continue to enjoy the improvements as we strive to make startup faster each release!