What is Allocating Space at the install ?

So I decided to do a little test. I have a 512gb solid state drive which generally has a incredible read/write time. (540 meg/s). So far the allocating space has taken 45 minutes and it is not nearly half way done. I popped open procmon to see what the client was ACTUALLY doing. Here is a sample:

Offset: 4,382,183,424
Length: 4,096
I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
Priority: Normal

Mind you this is non-cached and is writing 4096 bytes a good 200 times a second. This is just bad coding principles. Even microsoft can reserve file space faster than this and there is little to no reason to limit the buffer to 4096 bytes :P. Dump data shows it's writing nulls to file, along with cstring file names here and there (I imagine that's where it marks the parse points)

Just wanted to add my $.02 to this:

IMHO such an unusual installation procedure needs to be explained. Suggestions: Do so right in the 'Allocating Space...' window. Implement a progress tracker that shows where you are in the overall installation process. Implement some sort of ETC.

That said I would prefer a more conventional installation procedure, even if it was lazily programmed and took double the space of the final installation, e.g. by starting parallel processes to allocate space and to download required data. At the current TB/$ rate a few GB won't break anybody's set-up except in very rare circumstances (and you could warn those people beforehand by doing a quick freedisk check.)

Finally, the "defrag your disk" idea that gets tossed around in this thread strikes me as a bit... odd considering the advent of SDDs and current OS performance. Blast from the past, really. I wish people would stop obsessing about their HDDs looking pretty and consider the economical and physical consequences of defrag'ing instead (e.g., most importantly, significantly reduced [S|H]DD life expectancy with no practical performance gain to show for it).

Last time I checked they're now using their content API which interfaces with disk via section objects. Same method they use throughout the game which is poorly implemented; deferring responsibility of storage caching to windows is not a magical solution.

The reason it takes so long is due to the arbitrary disk access pattern which in turn is partially due to the archive's structure and partially due to how they're interfacing with it. Doing it this way ensures consistency.

There is no concept of a block size in the archive format; if there were then each file should be aligned on a 64k boundary so that requests can be mapped without be rounded. The archive format is extremely simple.

I find it interesting how people are complaining about a SINGLE instance of an issue within a FREE game in BETA. As Total Biscuit has said "Beta is Beta", aka still being worked on, so maybe the developers are working on making the best game they can before they work on the optimal method of installing said game? Not to mention that I have, in all honesty, an obsolete computer and in the time it took me to write this message plus ten minute prior of Allocating before I came to see what actually happens during this step because I was curious (edit) I finished allocating (end of edit). So, if you have an issue, post that you have the issue with your specs and be done with it, anymore griping beyond that is unneeded for the developers to address the issue.

I understand your argument, so I really hope this will change. The currently operation drowns in syscalls. On linux under wine, I get a ton of these:

"

mmap2(0x1ca0000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x1ca0000
mmap2(0x1ca0000, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 17, 0xcc6b0000) = 0x1ca0000
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0
mmap2(0x1ca0000, 4096, PROT_NONE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x1ca0000
rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [HUP INT USR1 USR2 ALRM CHLD IO], 8) = 0
write(3, "\23\0\0\0\0\0\0\0\0\0\0\0\324\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
read(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 64) = 64
rt_sigprocmask(SIG_SETMASK, [HUP INT USR1 USR2 ALRM CHLD IO], NULL, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [HUP INT USR1 USR2 ALRM CHLD IO], [], 8) = 0

So it basically needs at least 2 syscalls to map a 4k region of memory, insane. This piece of strace basically repeats over and over. No surprise it takes ages to allocate the space.

I am just now installing this game for the first time and wondering what is going on.

My guess would be that Content.ggpk is either a filesystem-in-a-file or a database, and that they write it out full of null before they download anything into it.

Just a guess, and probably a wrong one- not sure why anyone would do that unless it was just a case of an early temporary system scaling poorly once the game got larger.

This is still an issue with the installation, "Allocation Time". Read through all posts/replies and while yes Beta is indeed Beta, and most people have an idea of the, supposed, "Bug".

Why hasn't a Technical Support person made an official comment to the cause?

Oh man, just registered and this allocation stuff is already taking 4x longer than creating a 40GB vmWare virtual disk with full allocation. :(