What goes on behind the loading screen

The loading screen—it’s something we see quite often that we don’t want to see for very long. When we see it, however, it’s not just indicating that the application is just transferring data from storage to memory (the “loading” part); the application also has some work to do on the data it’s transferring before it’s ready for user interaction. This article will discuss what’s going on during application loading and take look at system characteristics of interest during the “loading” screens of a few programs.

The Lifecycle of an Application

The lifecycle of an application can be summed up in the following flowchart.

When you see a loading screen, what’s usually going on is that it’s hiding the steps being taken by the application: it’s what you see when data is being transferred and when the program is being initialized. (There are exceptions, like branding videos that play when you load a game, regardless of whether the program is loading data or not, but that's a different topic.) Sometimes not everything is brought in at once during loading, so the application may transfer some things, process them, then transfer more things, repeating the cycle until complete. While applications may provide some minor interactivity (such as showing tips), the application won’t be ready to use as intended until it hits the “ready” state.

Transferring the Data

Transferring data is when data moves from storage to RAM and is often the most visible to the user. If you launch the application from faster storage, then the process of moving data into RAM is faster. While raw bandwidth is important, what really hurts overall transfer speed is how many files need to be transferred. For every file transferred, the drive has to look up the location and then go and find it; this is called seek time. To give an example of how the number of file requests impacts performance, let’s take two transfer scenarios:

• Transferring one million 1KB files, totaling 1GB
• Transferring a single 1GB file

Let's say we have Storage Device A that has 1GB/s bandwidth and an average file seek time of 5ms and Storage Device B with 100MB/s and an average file seek time of 0.05ms. Taking these two devices:

• Device A will transfer the 1,000,000 1KB files in about 5,000 seconds, or about an hour and 23 minutes. It will transfer the single 1GB file in a second.
• Device B will transfer the 1,000,000 1KB files in about a minute. It will transfer the 1GB file in about 10 seconds.

While there aren’t any realistic scenarios where you’d move a million files, you can still improve things if you’re stuck with a hard drive. For games, developers like to clump assets into large files. This allows the game to do only one file request for multiple assets. All the game has to do is command “Go to this file and get data from these locations in that file.” Seeking still occurs, but it doesn't occur quite as often.

Other applications may be highly modular and contain a lot of separate plugins. This results in a lot more file transfer requests and will add to the loading time.

Initializing the Environment

Once an application is in RAM, technically, it starts running. The problem is that it’s not actually usable yet. For example, Linux goes through the following steps to start up (summary from IBM):

• Load a compressed image of the kernel into RAM
• Decompress the image and start up the kernel
• Initialize the hardware depending on its environment
• Start up “Init” or in some distributions “systemd”
• Init will spawn other processes depending on the configuration, before eventually giving the user a terminal or GUI for interaction

A lot of these steps are processing and have little to do with actually transferring data from storage to RAM. This implies that the processor is responsible for some of the “loading” that goes on in launching an application, so improving the processor’s performance can help make these steps go faster.

A Look Behind the Scene

To see what’s going on during loading, we’ll load up a few applications and monitor them using the Windows Performance Monitor tool. Because loading an application is affected by both the processor and storage medium, we’ll be looking at the following traits:

• Processor utilization
• Bytes per second being read
• Disc reads performed each second

We’ll look at the following applications:

• Grand Theft Auto V – Loading from a save file (recording stops as soon as game is playable)
• Portal 2 – Starting a new game (recording stops as soon as game is playable)
• Linux Mint – From boot to desktop
• Windows 7 – From boot to desktop

Linux Mint and Windows 7 were run from Oracle’s VirtualBox, as there’s no way of measuring this data otherwise.

The hardware setup is as follows:

Loading GTA V

GTA V has two spikes of loading data with moderate processing until the end, where it appears to finalize a lot of things at once before dropping off once the game is ready. In this case, the 2GHz CPU with an SSD takes about as long to load the level as the 4GHz CPU with a hard drive.

Loading Portal 2

Portal 2 loads lots of data at the beginning and a lot of smaller files toward the end, as indicated by the spike of read ops and low bandwidth. It doesn’t appear to do a whole lot of processing, which makes sense, as Portal 2 is an older game, and levels are scripted and static, unlike GTA V’s dynamic world of Los Santos. The slower CPU with an SSD ends up being just slightly ahead of the faster CPU with HDD in this scenario.

Loading Linux Mint

Linux, or at least this distribution, loads up a lot of things at once. This is most likely the kernel, which is kept small, and basic system programs. The rest of the loading and processing is most likely setting up the environment, which includes loading up hardware drivers, starting up services (like networking), and launching the interface. Here the fast CPU with HDD beats the slow CPU with SSD, though this is a clean install and adding more drivers and programs to a system can turn the tables.

Loading Windows 7

Windows 7 is similar to Linux, starting with a bulk transfer but then spending time processing and loading up more files over time. What’s also interesting is the unexpectedly low read bandwidth. Since the hard drive is similarly affected with lower than expected read bandwidth, this may mean Windows asks for a lot of smaller files and a bulk of the read time is spent seeking.

Unlike Linux, despite being a clean install, Windows greatly benefits from running on an SSD. The slower CPU clock takes about 21 seconds to finish booting, compared to just under 15 seconds on a fast CPU with SSD. Meanwhile, the use of a hard drive pushes the boot time to 43 seconds with a fast CPU and 47 seconds with a slow CPU. This particular test case illustrates why so many people find SSDs to be beneficial. It's also worth noting that Windows will frequently evict data from RAM and into the swap file, which means even after the initial loading you can still encounter delays with SSD vs. HDD storage.

Overall, it’s a combination of processing power and storage speed

A balance of processing power and storage speed affect the loading times of applications. While the data above doesn't extrapolate exact times when the application is transferring data and when it’s processing, we can take away a few things from the results we’ve seen:

• Transferring data appears to happen in bursts. With an SSD, these bursts appear as spikes as they can transfer data faster.
• A faster processor can decrease load times; the impact depends on the application.
• In some cases, having a faster processor with a hard drive can come close to performing as well as a slower processor with an SSD.

Ultimately, once a program is loaded, it generally won't have to go through this procedure again. The exception, as stated above, is operating systems, which do a lot more interaction with storage than most applications. While we definitely recommend including an SSD in your build, having a faster processor is still important. Particularly with gaming, a slower processor will hurt more over time than a hard drive. Considering it's easier to upgrade storage than the processor, and you can reuse your old drive as secondary storage, don't be afraid to start with a cheap HDD and a faster CPU and then upgrade to an SSD when you're able.