The actual source (https://store.steampowered.com/news/app/553850/view/49158394...) says:

> Only a few seconds difference?

> Further good news: the change in the file size will result in minimal changes to load times - seconds at most. “Wait a minute,” I hear you ask - “didn’t you just tell us all that you duplicate data because the loading times on HDDs could be 10 times worse?”. I am pleased to say that our worst case projections did not come to pass. These loading time projections were based on industry data - comparing the loading times between SSD and HDD users where data duplication was and was not used. In the worst cases, a 5x difference was reported between instances that used duplication and those that did not. We were being very conservative and doubled that projection again to account for unknown unknowns.

> Now things are different. We have real measurements specific to our game instead of industry data. We now know that the true number of players actively playing HD2 on a mechanical HDD was around 11% during the last week (seems our estimates were not so bad after all). We now know that, contrary to most games, the majority of the loading time in HELLDIVERS 2 is due to level-generation rather than asset loading. This level generation happens in parallel with loading assets from the disk and so is the main determining factor of the loading time. We now know that this is true even for users with mechanical HDDs.

They measured first, accepted the minimal impact, and then changed their game.

> They measured first,

No, they measured it now, not first. The very text you pasted is very clear about that, so I'm not sure why you're contradicting it.

If they had measured it first, this post would not exist.

But this means that before they blindly trusted some stats without actually testing how their game performed with and without it?

Yes, but I think maybe people in this thread are painting it unfairly? Another way to frame it is that they used industry best practices and their intuition to develop the game, then revisited their decisions to see if they still made sense. When they didn't, they updated the game. It's normal for any product to be imperfect on initial release. It's part of actually getting to market.

To be clear, I don't think it's a huge sin. It's the kind of mistake all of us make from time to time. And it got corrected, so all's well that ends well.

FWIW, the PC install size was reasonable at launch. It just crept up slowly over time.

    But this means that before they blindly trusted 
    some stats without actually testing how their 
    game performed with and without it?

Maybe they didn't test it with their game because their game didn't exist yet, because this was a decision made fairly early in the development process. In hindsight, yeah... it was the wrong call.

I'm just a little baffled by people harping on this decision and deciding that the developers must be stupid or lazy.

I mean, seriously, I do not understand. Like what do you get out of that? That would make you happy or satisfied somehow?

Go figure: people are downvoting me but I never once said developers must be stupid or lazy. This is a very common kind of mistake developers often make: premature optimization without considering the actual bottlenecks, and without testing theoretical optimizations actually make any difference. I know I'm guilty of this!

I never called anyone lazy or stupid, I just wondered whether they blindly trusted some stats without actually testing them.

> FWIW, the PC install size was reasonable at launch. It just crept up slowly over time

Wouldn't this mean their optimization mattered even less back then?

    premature optimization

One of those absolutely true statements that can obscure a bigger reality.

It's certainly true that a lot of optimization can and should be done after a software project is largely complete. You can see where the hotspots are, optimize the most common SQL queries, whatever. This is especially true for CRUD apps where you're not even really making fundamental architecture decisions at all, because those have already been made by your framework of choice.

Other sorts of projects (like games or "big data" processing) can be a different beast. You do have to make some of those big, architecture-level performance decisions up front.

Remember, for a game... you are trying to process player inputs, do physics, and render a complex graphical scene in 16.7 milliseconds or less. You need to make some big decisions early on; performance can't entirely just be sprinkled on at the end. Some of those decisions don't pan out.

    > FWIW, the PC install size was reasonable at launch. It just crept up slowly over time

    Wouldn't this mean their optimization mattered even less back then?

I don't see a reason to think this. What are you thinking?

> One of those absolutely true statements that can obscure a bigger reality.

To be clear, I'm not misquoting Knuth if that's what you mean. I'm arguing that in this case, specifically, this optimization was premature, as evidenced by the fact it didn't really have an impact (they explain other processes that run in parallel dominated the load times) and it caused trouble down the line.

> Some of those decisions don't pan out.

Indeed, some premature optimizations will and some won't. I'm not arguing otherwise! In this case, it was a bad call. It happens to all of us.

> I don't see a reason to think this. What are you thinking?

You're right, I got this backwards. While the time savings would have been minimal, the data duplication wasn't that big so the cost (for something that didn't pan out) wasn't that bad either.