Instead of y'know, running their own game on a hdd.

It's literally "instead of profiling our own app we profiled competition's app and made decisions based on that".

If I’m being charitable, I’m hoping that means the decision was made early in the development process when concrete numbers were not available. However the article linked above kinda says they assumed the problem would be twice as bad as the industry numbers and that’s… that’s not how these things work.

That’s the sort of mistake that leads to announcing a 4x reduction in install size.

>In the worst cases, a 5x difference was reported between instances that used duplication and those that did not.

Never trust a report that highlights the outliers before even discussing the mean. Never trust someone who thinks that is a sane way to use of statistics. At best they are not very sharp, and at worst they are manipulating you.

> We were being very conservative and doubled that projection again to account for unknown unknowns.

Ok, now that's absolutely ridiculous and treating the reader like a complete idiot. "We took the absolute best case scenario reported by something we read somewhere, and doubled it without giving a second thought, because WTF not?. Since this took us 5 seconds to do, we went with that until you started complaining".

Making up completely random numbers on the fly would have made exactly the same amount of sense.

Trying to spin this whole thing into "look at how smart we are that we reverted our own completely brain-dead decision" is the cherry on top.

But if I read it correctly (and I may be mistaken) in actual practice any improvement in load times was completely hidden by level generation that was happening in parallel, making this performance improvement not worth it, since it was hidden by the other process.