← All posts

From twelve gigabytes down to three

We shipped 0.2.4 with a bad habit: a minute after Start, the game could be holding 10 to 12 GB of RAM. On a 16 GB machine that leaves almost nothing for the rest, and even on a bigger one it is a game that stutters every time Windows has to give something back. A few of you also hit a freeze on a venue door.

We spent the day on it, measuring each change on the Shipping build, the one you play, not the editor.

RAM, in gigabytes
Now, back outside Now, inside a venue (worst seen) Now, on the map 0.2.4, a minute after Start 2.9 5.9 2.3 12

0.2.4 sat at 10 to 12 GB. Now: 2.3 GB on the map, 3.2 to 5.9 GB inside a venue, 2.6 to 2.9 GB again after leaving it.

What was holding it

In order of size.

  • Clothes carried the whole body. One pair of trousers stored 279 body shapes, dense, for every vertex of the garment. We now keep only the shapes the game actually drives. And the tiny movements nobody can see (under a tenth of a millimetre) are now exactly zero instead of a faint tail on every vertex: a stored shape went from 4.3 MB to 0.45.
  • Strangers waiting in the basement. At Start the game dressed 24 strangers and hid them under the map, ready to fill a venue, and every venue you left gave its strangers back to that pool without limit. At about 600 MB a head, that was the biggest block. There is no pool any more: strangers are made when a venue needs them, and removed when you leave.
  • Furniture, a pack at a time. Entering a venue read 22 to 26 whole furniture packs, 1.5 to 2 GB, to place around thirty pieces, and kept them all for the visit. Packs are now split per piece, read four at a time, and released as soon as the room is built.
  • Caches that never let go. The mod and room caches grew for the whole session. They now keep what is still on screen and free the rest, at Start and each time you leave a venue.
  • Textures read twice. On nearly half the installed files the full-size PNG won over its compressed DDS twin. The compressed one now always wins, and body hair, tattoos, makeup and tan lines got compressed versions of their own.

The freeze on the venue door

This one was subtler. While a garment was being built in the background, nothing held it for one frame, and if the garbage collector ran in that frame, the game finished dressing someone with a mesh that no longer existed. It is held now until it is safely in the cache.

The door freeze itself was a deadlock between two threads, each waiting for the other: the model parser needed the game thread for its base materials while our loader held the garbage collector's guard, and a collection due on the game thread waited for that same guard. The base materials are now loaded once and copied. And if the game ever stops drawing frames for fifteen seconds again, it writes every thread's stack to a file, so the next one is not a mystery.

Also in this build

  • Ray tracing is off by default. It was on for everybody, paid for in video memory and frame time by cards that cannot use it well. Settings has a switch to turn it back on live. It changes nothing for system RAM; the saving is on the GPU.
  • The colour you pick for a garment now reaches the game. In the creator it was applied on the preview and then lost on the way to the city.
  • A content warning on the first loading screen of each launch.

There is still a long way to go: 2 to 6 GB is fine, but it should be lower inside a venue. We will keep measuring.