Where a minute of loading goes

A new world on a seed nobody has used before has to be generated from nothing. Early on November 9, on the test machine, it took about 61 to 63 s from pressing Create to walking. The loading page was 32 s of that every time. That is its limit, raised from 25 s on October 31.

Worlds started before were already quicker, their ground read back from disk since November 6. A new seed gets nothing from that, and test sessions begin on one.

So the stages of a new-seed load were timed, and the first finding was not about speed. The far forest got no work at all before the player had control: its pieces were waiting on far terrain tiles that had been sent off before the forest was attached to them, so nothing built them while the page was up. The sharp far tiles in view, the longest jobs under the page at 20 to 31 s each, started late: 6 of 12 began 25 s late, because the workers held back for them were miscounted.

Both were made to start early. It saved no time: one test world went from 61.2 s to 60.9 s. What changed was what the wait bought. Where 4 to 11 pieces of far forest and 3 to 6 sharp far tiles had been missing when the page lifted, the forest was complete and the tiles all or nearly all there.

BeforeAfter

The seconds came off in smaller pieces the same day. The page had been waiting for 20 steady frames under 33 ms, so a scene running at 34 to 36 ms could never be called ready. A frame now counts as steady when it is close to the frames just before it, and one run lifted at 26.9 s. With a faster search for the start as well, one world went from a mean of 63.6 s to 58.2 s.

Later that day a fixed test world stopped loading. With the first of these changes in, the ground around its start missed a 180 s deadline. Lighting data for cliffs and steep slopes was built by background workers that run below normal priority, and under the loading page every core is busy, so a block of ground could wait on patches held by a starved worker. Before any load change, the block of that world with the most steep ground had already taken 81 s; in the run that missed the deadline it took 123 s. The stall had been there all along and struck unevenly from run to run; the earlier starts had added enough work under the page to push one run over the line. Steep patches under the page are now built at normal priority, and that block took 2.1 s.

The largest measured saving came from time nobody was using. Test sessions had sat on the main menu for 97 to 258 s with nothing being prepared, because a blank seed field was only given its seed when Create was pressed. From November 12 the menu, once it has been up for 2 s, picks the seed a blank field will use and starts on that world: the search, then the ground around the camp. After 20 s on the menu, on a machine busy with other work, two test worlds went from 80.5 to 51.7 s and from 103.7 to 80.8 s, the same worlds either way. Hours later the menu began preparing the far tiles in view and their forest too.

Far tiles not preparedFar tiles prepared

The gain is uneven. With the far tiles prepared, one world’s page lifted ready with all 12 in place, where without them it had timed out with 5 tiles and 11 blocks of far forest missing. Yet click to control was 65.1 s, against 69.0 s with no menu preparation at all, one run each. The page itself is now the long part.

The last attempt, on November 14, went the other way. One stage of a new-seed load, setting up lakes, creek routes and basins for the first block of ground, ran for 55 to 75 s on a single worker while the other cores sat idle. Lending it 8 threads took the first block from 69.6 to 39.3 s on a busy bench. In the game, single loads measured 74.3 s without the lending and 88.2 s with it, and it was switched off within the hour. Why borrowed cores slow the ground down is not known yet.