• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Why games load so slow?

Joined
Sep 1, 2020
Messages
2,673 (1.56/day)
Location
Bulgaria
I find a partial answer of this question in one of competitive forums. Will not make advertising of it's name. Here is this answer:

Loading times in games are caused by:
  1. decompression, responsible for about 30% of loading times
  2. drm like Denuvo, responsible for about 40%-60% of loading times

What you think about?
 
When you say "games", which ones do you mean?
Some load incredibly fast, some load slower. Not all games load at nearly the same speed.

There are games that load assets directly to your GPU VRAM to fill it up and might take longer, there are games where data streaming is preferred and don't do much pre-loading. Games are programmed vastly differently in this regard.
 
When you say "games", which ones do you mean?
Some load incredibly fast, some load slower. Not all games load at nearly the same speed.

There are games that load assets directly to your GPU VRAM to fill it up and might take longer, there are games where data streaming is preferred and don't do much pre-loading. Games are programmed vastly differently in this regard.
I have quoted what I have read. The other reasons for differences in loading speed are in the design of the games themselves. How large are the scenes and how many small files are there in the individual scenes.
 
Last edited:
Just put all your slow loading games on NVMe PCIe 4.0, I do that, GTA V loads pretty quickly, also have Forza Horizon 5 on it....
 
Read this:
 
DRM contribution is greatly exaggerated.

From the top of my head, loading time = f(typical disk I/O, asset decompression, shader caching/prewarming/whatever, scene creation maths (e.g. procedural gen), dev laziness, combobulating discombobulator).
 
After owning an Acorn Electron and a Spectrum 48k in the 80's, loading times nowadays are always blazing fast to me, even from an HDD :laugh:
Oh man that takes me back! :)
 
What, loading games from cassettes tape?... Yes I've done that!.. :D
When loading time matched your typing time because game code was printed in a magazine.
 
DRM contribution is greatly exaggerated.
I haven't quoted the whole answer in the other forum and that's for reasons. But I will add that all files are checked for copyrighted content. When many small files are contained, the total game scene load time increases significantly. Another reason is that the comparison is made on the Denuvo servers and their load and the qualities of the internet access of the particular internet access, not so much as linear speed, but as latency and ordering of data packets for check files, also add time. In general, it appears that factors other than the random reading speed of small files on the storage device itself are the reasons why game scenes load much slower than they should. I would guess that without all the interfering extra factors, scenes in games would load in no more than 4-5 seconds on average from a relatively modern and fast SSD.
 
When loading time matched your typing time because game code was printed in a magazine.

Never had such magazine but we've had coding books in the past which contained that code to create games.. :laugh:
 
Never had such magazine but we've had coding books in the past which contained that code to create games.. :laugh:
We used to have radio shows in Poland which would broadcast the games so you could record them using your tape deck.
 
GTV5: flies over the city with parachute, lands anywhere he wants, no loading

Tomb Raider: falls into the river 2 meters below, dies, shows loading screen.
 
DRM contribution is greatly exaggerated.

From the top of my head, loading time = f(typical disk I/O, asset decompression, shader caching/prewarming/whatever, scene creation maths (e.g. procedural gen), dev laziness, combobulating discombobulator).
Don't forget the reticulation of splines. :cool:

Also, from my experience playing modded Skyrim (and other Bethesda games), the total size and files count of game addons and mods play a big role too. Once had a moderately-sized load order that made me wait like 1.5 minutes for Skyrim to load, from the moment I open the game to when the main menu shows up.
 
Just put all your slow loading games on NVMe PCIe 4.0, I do that, GTA V loads pretty quickly, also have Forza Horizon 5 on it....

For this reason alone I consider the 2TB NVMe drive as worth it for me. I tend to not play for long stretches of time, and doing a quick session after work is a lot more palatable if you don't have to wait 3 minutes (Stellaris) before you're in the game.
 
Oh man that takes me back! :)

Yes, i remember it failing to load and having to adjust the heads to fine tune some haha.
 
Yes, i remember it failing to load and having to adjust the heads to fine tune some haha.
Don't get me started on cassettes, especially for supposedly "hifi" audio.
 
Don't get me started on cassettes, especially for supposedly "hifi" audio.

Me either as i have heard some dam good audio tapes over the years, although a total pain the ass as everyone records differently and so many factors.
 
But I will add that all files are checked for copyrighted content. When many small files are contained, the total game scene load time increases significantly. Another reason is that the comparison is made on the Denuvo servers and their load and the qualities of the internet access of the particular internet access, not so much as linear speed, but as latency and ordering of data packets for check files, also add time.
Citation?
As far as I recall, the anti tamper only checks [some] executable code. That's a very small fraction of a game's data.

Internet connection is only required to fetch an activation token (that I doubt would exceed a few bytes to kilobytes in size), obtained periodically (i.e. not at every asset/level load op), and validated once at launch time.
So, even if one is using a third world ISP, they'd be looking at a second or two delay in launch every few weeks or whatever expiry dates these tokens have.

I'm not saying that anti-tampering mechanisms don't affect load times. What I'm saying is the that the effect stated above (40~60%) is exaggerated.
 
DRM contribution is greatly exaggerated.

From the top of my head, loading time = f(typical disk I/O, asset decompression, shader caching/prewarming/whatever, scene creation maths (e.g. procedural gen), dev laziness, combobulating discombobulator).

Denuvo is shown to increase game and level loading times:
By 40-60% though? No in the vast majority of cases, it's often in the 10-20% range.

Shader caching should only happen on the first load. Worst case, the game caches while running but it still only needs to do so once.

What causes long loading times varies a lot depending on the size and amount of the game assets, how those assets are stored, how well optimized the loading routine is, and how much work the game needs to do to get the game world running.

Citation?
As far as I recall, the anti tamper only checks [some] executable code. That's a very small fraction of a game's data.

Internet connection is only required to fetch an activation token (that I doubt would exceed a few bytes to kilobytes in size), obtained periodically (i.e. not at every asset/level load op), and validated once at launch time.
So, even if one is using a third world ISP, they'd be looking at a second or two delay in launch every few weeks or whatever expiry dates these tokens have.

I'm not saying that anti-tampering mechanisms don't affect load times. What I'm saying is the that the effect stated above (40~60%) is exaggerated.

DRM like Denuvo bloats the EXE file size and it always running in the background. This is why the same game with Denuvo runs worse then without. DRM that only looks for a simple activation token at launch are easily crack-able.
 
Denuvo is shown to increase game and level loading times:
Technically speaking, the only thing shown here is a comparison between two (or three) different builds of some games. Concluding that change in results is attributed to one element or the other is, frankly, a reach.
I am inclined to believe the majority of this 10-20% difference can be attributed to Denuvo, but I'd be careful in picking tests to back this belief. The fact that implementation of the tech itself depends greatly on developer choices makes me even more wary of generalized conclusions.

Shader caching should only happen on the first load. Worst case, the game caches while running but it still only needs to do so once.
Depends...
Drivers (probably) always do serialize/cache device-specific objs from shader programs passed by the engine, but the engine itself doesn't always have those shaders ready to pass on to the drivers. At least with Unity, the game needs to load and decompress specific shader programs for every scene, and in some cases do off-screen rendering to trigger driver-side compilation, the results of which could be already cached, but the off-screen rendering overhead remains.

What causes long loading times varies a lot depending on the size and amount of the game assets, how those assets are stored, how well optimized the loading routine is, and how much work the game needs to do to get the game world running.
I agree.

DRM like Denuvo bloats the EXE file size and it always running in the background. This is why the same game with Denuvo runs worse then without. DRM that only looks for a simple activation token at launch are easily crack-able.
Mostly agreed.
My previous post mentioned the tokens only for the internet connection requirement part. This component of the anti tampering mechanisms has little effect on the overall loading time. I never claimed that Denuvo only does token validation. The second sentence of the post you've quoted clearly states another mechanism.

Regarding the executable size, I don't think there would be much difference in real world performance whether Denuvo code was statically (one big exe) or dynamically linked (small exe with a ton of dlls). What the extra code does has an effect, but how it's loaded most likely don't.
 
Technically speaking, the only thing shown here is a comparison between two (or three) different builds of some games. Concluding that change in results is attributed to one element or the other is, frankly, a reach.
I am inclined to believe the majority of this 10-20% difference can be attributed to Denuvo, but I'd be careful in picking tests to back this belief. The fact that implementation of the tech itself depends greatly on developer choices makes me even more wary of generalized conclusions.


Depends...
Drivers (probably) always do serialize/cache device-specific objs from shader programs passed by the engine, but the engine itself doesn't always have those shaders ready to pass on to the drivers. At least with Unity, the game needs to load and decompress specific shader programs for every scene, and in some cases do off-screen rendering to trigger driver-side compilation, the results of which could be already cached, but the off-screen rendering overhead remains.


I agree.


Mostly agreed.
My previous post mentioned the tokens only for the internet connection requirement part. This component of the anti tampering mechanisms has little effect on the overall loading time. I never claimed that Denuvo only does token validation. The second sentence of the post you've quoted clearly states another mechanism.

Regarding the executable size, I don't think there would be much difference in real world performance whether Denuvo code was statically (one big exe) or dynamically linked (small exe with a ton of dlls). What the extra code does has an effect, but how it's loaded most likely don't.

This is a very well thought out reply, I appreciate you taking the time to write it.
 
Tomb Raider: falls into the river 2 meters below, dies, shows loading screen.
I've never understood why that happens. The game assets are already in your RAM, so all you need is to go back to your position a couple seconds earlier. Why does that have to take an eternity?
 
  • Like
Reactions: Lei
Back
Top