5 ms·
How is there so much duplication?
by andrewstuart 11mo ago
How is there so much duplication?
- jy14898 11mo agoThe post stated that it was believed duplication improved loading times on computers with HDDs rather than SSDs
- dontlaugh 11mo agoWhich is true. It’s an old technique going back to CD games consoles, to avoid seeks.
- SergeAx 11mo agoIs it really possible to control file locations on HDD via Windows NTFS API?
- dontlaugh 11mo agoNo, not at all. But by putting every asset a level (for example) needs in the same file, you can pretty much guarantee you can read it all sequentially without additional seeks. That does force you to duplicate some assets a lot. It's also more important the slower your seeks are. This technique is perfect for disc media, since it has a fixed physical size (so wasting space on it is irrelevant) and slow seeks.
- viraptor 10mo ago> by putting every asset a level (for example) needs in the same file, you can pretty much guarantee you can read it all sequentially I'd love to see it analysed. Specifically, the average number of nonseq jumps vs overall size of the level. I'm sure you could avoid jumps within megabytes. But if someone ever got closer to filling up the disk in the past, the chances of contiguous gigabytes are much lower. This paper effectively says that if you have long files, there's almost guaranteed gaps https://dfrws.org/wp-content/uploads/2021/01/2021_APAC_paper-a_contemporary_investigation_of_ntfs_file_fragmentation.pdf https://dfrws.org/wp-content/uploads/2021/01/2021_APAC_paper... so at that point, you may be better off preallocating the individual does where eating the cost of switching between them.
- dontlaugh 10mo agoSure. I’ve seen people that do packaging for games measure various techniques for hard disks typical of the time, maybe a decade ago. It was definitely worth it then to duplicate some assets to avoid seeks. Nowadays? No. Even those with hard disks will have lots more RAM and thus disk cache. And you are even guaranteed SSDs on consoles. I think in general no one tries this technique anymore.
- toast0 10mo agoFrom that paper, table 4, large files had an average # of fragments around 100, but a median of 4 fragments. A handful of fragments for a 1 GB level file is probably a lot less seeking than reading 1 GB of data out of a 20 GB aggregated asset database. But it also depends on how the assets are organized, you can probably group the level specific assets into a sequential section, and maybe shared assets could be somewhat grouped so related assets are sequential.
- wcoenen 10mo ago> But if someone ever got closer to filling up the disk in the past, the chances of contiguous gigabytes are much lower. By default, Windows automatically defragments filesystems weekly if necessary. It can be configured in the "defragment and optimize drives" dialog.
- pixl97 10mo agoNot 'full' de-fragmentation, Microsoft labs did a study and after 64MB slabs of contiguous files you don't gain much so they don't care about getting gigabytes fully defragmented. https://web.archive.org/web/20100529025623/http://blogs.technet.com/b/filecab/archive/2006/07/10/disk-defragmenter-faq.aspx https://web.archive.org/web/20100529025623/http://blogs.tech... old article on the process
- justsomehnguy 10mo ago> But if someone ever got closer to filling up the disk in the past, the chances of contiguous gigabytes are much lower Someone installing a 150GB game sure do have 150GB+ of free space and there would be a lot of continuous free space.
- toast0 10mo agoNot really. But when you write a large file at once (like with an installer), you'll tend to get a good amount of sequential allocation (unless your free space is highly fragmented). If you load that large file sequentially, you benefit from drive read ahead and OS read ahead --- when the file is fragmented, the OS will issue speculative reads for the next fragment automatically and hide some of the latency. If you break it up into smaller files, those are likely to be allocated all over the disk; plus you'll have delays on reading because windows defender makes opening files slow. If you have a single large file that contains all resources, even if that file is mostly sequential, there will be sections that you don't need, and read ahead cache may work against you, as it will tend to read things you don't need.
- pjc50 10mo agoKey word is "believed". It doesn't sound like they actually benchmarked.
- wongogue 10mo agoThere is nothing to believe. Random 4K reads for HDD is slow.
- debugnik 10mo agoI assume asset reads nowadays are much heavier than 4 kB though, specially if assets meant to be loaded together are bundled together in one file. So games now should be spending less time seeking relative to their total read size. Combined with HDD caches and parallel reads, this practice of duplicating over 100 GBs across bundles is most likely a cargo-cult by now. Which makes me think: Has there been any advances in disk scheduling in the last decade?
- khannn 10mo agoWho cares? I've installed every graphically intensive game on SSDs since the original OCZ Vertex was released.
- teamonkey 10mo agoTheir concern was that one person in a squad loading on HDD could slow down the level loading for all players in a squad, even if they used a SSD, so they used a very normal and time-tested optimisation technique to prevent that.
- khannn 10mo agoTheir technique makes it so that the normal person with a ~base SSD of 512 GB can't reasonably install the game. Heck of a job Brownie.
- breve 11mo agoThey duplicate files to reduce load times. Here's how Arrowhead Game Studios themselves tell it: https://www.arrowheadgamestudios.com/2025/10/helldivers-2-tech-blog-1-install-size/ https://www.arrowheadgamestudios.com/2025/10/helldivers-2-te...
- imtringued 11mo agoI don't think this is the real explanation. If they gave the filesystem a list of files to fetch in parallel (async file IO), the concept of "seek time" would become almost meaningless. This optimization will make fetching from both HDDs and SSDs faster. They would be going out of their way to make their product worse for no reason.
- Xss3 11mo agoIf they fill your harddrive youre less likely to install other games. If you see a huge install size youre less likely to uninstall with plans to reinstall later because thatd take a long time.
- ukd1 10mo agoUnfortunately this actually is believable. SMH.
- toast0 10mo agoSolid state drives tend to respond well to parallel reads, so it's not so clear. If you're reading one at a time, sequential access is going to be better though. But for a mechanical drive, you'll get much better throughput on sequential reads than random reads, even with command queuing. I think earlier discussion showed it wasn't very effective in this case and taking 6x the space for a marginal benefit for the small % of users with mechanical drives isn't worth while...
- seg_lol 10mo agoEvery storage medium, including ram, benefits from sequential access. But it doesn't have to be super long sequential access, the seek time, or block open time just needs to be short relative to the next block read.
- crest 10mo agoThe idea is to duplicate assets so loading a "level" is just sequential reading from the file system. It's required on optical media and can be very useful on spinning disks too. On SSDs it's insane. The logic should've been the other way around. Do a speed test on start an offer to "optimise for spinning media" if the performance metrics look like it would help. If the game was ~20GB instead of ~150GB almost no player with the required CPU+GPU+RAM combination would be forced to put it on a HDD instead of a SSD.
- immibis 10mo agoThis idea of one continuous block per level dates back to the PS1 days. Hard drives are much, much faster than optical media - on the order of 80 seeks per second and 300 MB/s sequential versus, like, 4 seeks per second and 60 MB/s sequential (for DVD-ROM). You still want to load sequential blocks as much as possible, but you can afford to have a few. (Assuming a traditional engine design, no megatextures etc) you probably want to load each texture from a separate file, but you can certainly afford to load a block of grass textures, a block of snow textures, etc. Also throughput is 1000x higher than a PS1 (300 kB/s) so you can presumably afford to skip parts of your sequential runs.
- immibis 10mo agoI meant to write that you probably DON'T want to load each texture from a separate file, but it would be fine to have them in blocks.