The oldest Linux distribution still around, very technical, and the learning curve is rather steep, especially when you're coming from Ubuntu and the like, so clearly not one I would recommend for beginners. Otherwise, I highly recommend it because once it is set up and configured the way one wants it, it is second to none. When someone dabbles into the world of Linux, learning and mastering it is rewarding in itself. ;-)

There's definitely something wrong with the God Of War offline installer. It took over 2 hours to install the game on my PC beating the previous record of Cyberpunk 2077 which takes about 45 minutes.

I admit that my machine is far from optimal as I have a single NVMe SSD (650GB free before install and 99% healthy) and a 2700x CPU (not much point in having 16 hardware threads when the installer is single threaded) but this installer takes a ridiculously long time to run, even compared to other post-Galaxy installers.

It is the honest truth. I don't know why it takes so long, or - after trying it for a fourth time, this time from my general-purpose NVMe - the fastest and with the largest cache, and switching temp folders to one of the faster SSDs, I made the following observations: the installation process was quicker initially but then started to crawl at the end. The installer window got stuck on the desktop but did not hang; at one point, the installer window closed and another opened, seemingly starting over from the beginning. CPU and RAM are hardly used, and transfer rates vary, which I attribute to lots of very small files. The transfer rate over the whole duration doesn't fall below an average of 27.45 MB/s.

A sound advice.

That's something I can't confirm, startup was prompt and initial shader caching done by the GPU, so not much delay.

The CPU and RAM utilization remain consistently low throughout the installation process, and as far as I've observed using one of the monitoring tools, the swapfile is large enough and isn't utilized at all.

And how would I be able to check this?

I can confidently say that this isn't a likely source for this problem. Something weird is going on, I just can't say, what it is.

What massively slows GOG installers down in general is the (unnecessary) intermediate step of Galaxification, ie, since around 2018 GOG started packing installers (using InnoSetup) as "Galaxy Streams" stored as a bunch of data chunks with gibberish md5 hashes as filenames" that need to reference a Galaxy manifest to reconstruct them back to proper files. Testing the same games side by side newer vs older installers (that used the old 2.0.0.x file naming convention), several of us found Example 1, Example 2, that they are much much slower (and significantly slower vs unzipping a .7z / .rar backup file of the game folder (or a pre-supplied zip from itch.io) or rebuilding your InnoSetup installer "normally" without the Galaxy junk, but with multi-threaded vs single-threaded). The larger the game, the worse the problem.

This isn't the first we've seen artificially degraded GOG installers take +30mins to install a game, but I don't own the game to test if there's something else on top causing "2hrs on an NVMe SSD".

Thanks for the link, very interesting! It's the first time I've encountered it, and this isn't the first game with over 50GB. Could a finding that it is a Steam dump have anything to do with this rather strange behavior? Or the installer file size being 24MB?

Is it fair to say then, that this is a problem caused by their installers, and the way they work? If this is the case, do they correct it when they become aware of it?

Yep, there's something extra going on with this one. I didn't babysit it the whole time but it completed the verify step in the usual amount of time for a 12 file installer but then hung for about 15 minutes, during which time Task Manager showed 0% CPU activity and 0% disk activity and reported the process and it's two sub-processes as "Not Responding". I've not noticed this happening before with other installers.

It then woke up and proceeded to the install phase which crawled at the usual post-2018 speed for about 30 minutes. It then did the common thing where the progress bar exceeded the 100% limit, which usually happens after the game files have installed and the installer is doing post-install dependencies like DirectX and MSVC runtimes. It however didn't say it was installing these as it usually would.

But then it just sat there for another 90 minutes with one thread maxed out and a continuous 1.2Mb/s of disk activity. The GoW directory was at about 63.9GB before this and after the 90 minutes, it was at 64.3GB so it didn't appear to write much more data (or it was deleting and re-writing). Perhaps it was very slowly cleaning up temporary files. Or perhaps dtgreene is right and there is a shader pre-compilation happening as part of the installation process but that seems unlikely and, I believe, would be a first for a GOG installer.

I don't know what's inside God of War specifically (I don't own the game), but it affects most GOG games that were repackaged to the new installer format post 2016 that now install far slower than they need to. Smaller games just hide the slowdown effect better than larger ones.

They don't correct it as it's "working as designed", ie, we've ended up with these 'Galaxified' compromises because GOG now auto-build the offline installer from the Galaxy version. It's done more for GOG's convenience rather than being better for the end user. But even then, there's no real reason why GOG's installers (that use InnoSetup) can't just store files as files / use multi-threaded decompression by default, leading a lot of people to wonder if it's being done deliberately as a "negative incentive" feature to make Galaxy look artificially better. Same as there's been no real attempt to fix the other "offline installers hang for +15s waiting on Galaxy" bug for dozens of 2017-2023 games.

One possible explanation for the extreme slowness of this offline installer is the sheer number of files that make up the game: 156,589.

Most modern (and many older) games/engine would tend to use a packed binary file for most of their assets and avoid spraying loose files onto the disk like this. Hell, even my own game engine does this! But for some reason GoW doesn't, at least for a lot of its audio assets.

So given what we know about the packaging process of the current GOG offline installers (thanks AB2012 for the reminder), I imagine this sort of file distribution might pose a problem. I could of course be completely wrong though...

Unfortunately, Windows completely kneecapped the bluescreen process, it used to be you could get useful information such as memory registers and a cause of death. Though, taking a wild guess, GOG's installer is thrashing around hard because it's some incredibly old, inefficient tech and ends up ballooning in memory and thermal spaces until thermal failure points are reached.

Basically, because it hardlines one core, on one thread, instead of distributing the installer across all lanes, threads and cores, it just hammers the system by sitting on it all.

And someone would have to legally prod GOG in the ribs, because as stated above, this isn't a flaw of the software, but of the implementation.

If a system gets too hot it's a hardware cooling problem. Period. And the amount of memory being used has zero impact on this.

No. Using all available cores would tax the hardware more, not less. If it only uses a single core the OS can just move the process between cores as the temp for one gets near the allowable max.

That picture reasembles graphic corruption a lot, the kind of you deal with on overclocks or lack of power on laptops and SBC's.

My PC needs a fraction of this time and i am glad. I got several hundred games installed and it if would take that long for a single game, i would be totally doomed.
I wonder if there is a tool able to transform the "bad setup" into a "good setup"... this would be interesting.

It would make things so much faster for every new install and less stress on the hardware.
Yes, the game size is not necessarily a issue but the "amount of small and loose files"... because even the fastest drive will burn as soon as there are thousands of "micro files" involved. So, nope... even the fastest drive will either need data optimization or it will become doomed. There is not a single drive able to be faster than maybe 100 MB/s on totally randomly generated 4k file chunks.

I dont even know how they calculate "IOPS" but in my experience, at worst case... the IOPS is more like hundreds and not thousands of IOPS.
I can agree... CPU and RAM performance is close to no matter at all. If so... any install would be a rocket to me at 64 GB RAM and a cutting edge CPU with 3D cache. However, the limit is mainly on the install drive which simply is not utilized in a friendly way. I guess the most important spec is "single threaded small file writes", and luckily my cutting edge (990 Pro and Fury Renegade) game drives are very performant at this spec... but never sufficiently fast (still to slow to me). It can surely be much faster but it would need many threads at once, because a SSD is working fastest this way (on a HDD it is not a big matter, as they generally can not perform well under multi threaded workloads).

The installer drive, its speed is close to no matter at all... and it can be done by a HDD as well with close to SSD speed. Sometimes i even use the HDD... as there is close to no difference.

Besides the countless small files, which I also believe are part of what's causing this issue, it seems there's another aspect regarding how the installer works and its setup, which I found somewhat strange.

I've monitored part of the process and noticed that one of the three processes listed as ".temp," responsible for file extraction, remains in an idle state for most of the time. Meanwhile, the main installation process is constantly switching between writing, compressing, cleaning up - which seems to happen after each write-cycle, and other unnecessary tasks during that stage of the installation process. Instead of extracting files to a single temporary folder, they're spread across several, each containing up to 40 subdirectories with the same names and structures, each containing a myriad of very small files.

Process Explorer revealed that ".bls" and ".tls" are assigned a value of 0, even though they're not nullable when some other value isn't empty (I forgot which). A friendly support person mentioned something about TLS in their email, suggesting there might be a connection between the slow installation process and this installer setting being set to 0.


Maybe this is a solution, but certainly not the answer, as perhaps a change to the installer itself could fix it for everyone encountering that problem.

Excuse me, this is not my statement... i was just answering.

I can NOT live without a "optimal PC", it would cause me nightmares... kinda like "Alone in the Dark".

My time is very valuable and a PC able to save up on time (and hassle) is worth A LOT of coins to me.