Parallel generation
Meld splits the area into cells, builds many cells at the same time, and manages the CPU, memory, and disk so a long country build runs smoothly instead of choking your machine. This page covers each of those moving parts.
Cells and the worker pool
Why. One Arnis run is single threaded over a fixed box, so a big area is slow. Building many cells at once gives a several times speedup.
The mechanism. Meld splits the selection into region aligned cells, then a bounded worker pool runs up to N Arnis processes at once, one per cell. The pool feeds jobs as workers free up and tracks each worker’s current cell, percent, and message. Every cell is fed the same origin, seed, and height lock, so the tiles line up (the full reason is in How it works).
How to use it. Hit Plan to tile the selection, then Generate and merge. The Workers slider in Settings sets N (1 to 64, default 4). The safe ceiling is your machine, not a fixed number: keep workers times threads at or under your logical cores, and let Recommend size it for you. Changing the worker count mid run resizes the pool live. The left rail Workers card shows a row per worker so you can spot a slow or stuck cell at a glance.
CPU budget and threads
Why. If you let every worker grab all the cores, they fight each other and the machine sawtooths. If a high worker count starves each cell down to a single thread, each cell gets slow.
The mechanism. Meld divides a CPU budget across the workers and hands each one a share of threads, with a floor so no cell drops below a usable thread count. The budget is a percentage of your cores, so you can leave room for the rest of your system.
How to use it. In Settings, set CPU budget percent (default 90) and the minimum threads per worker (default 2). Most people never touch these; Recommend sets sane values for your PC.
Staggered starts and adaptive pacing
Why. If all the workers launch in lockstep, they all hit the same heavy phase (download, then build, then the big save burst) at the same moment, which spikes CPU and can run you out of memory mid save.
The mechanism. Meld offsets each worker’s first job by a small delay so they fall out of step and spread their heavy phases over time. The delay can be a fixed number of seconds, or adaptive, where Meld watches how long a cell actually takes and spaces starts to match.
How to use it. In Settings, toggle Stagger starts and Adaptive pacing, and set the stagger step in seconds. The defaults are fine for most machines.
Stream to disk for huge cells
Why. A very large cell (8 by 8 or 16 by 16 regions) held fully in memory would run you out of RAM before it finishes.
The mechanism. For big cells, Meld tells Arnis to write finished regions out to disk as it goes instead of keeping the whole world in memory, so a huge cell finishes inside a bounded memory footprint. It is delivered as an environment signal, so an older Arnis binary that does not know about it just ignores it.
How to use it. It turns on automatically for cell size 8 and up. You can force it on smaller cells with the Stream to disk toggle in Settings.
Auto retry
Why. An unattended overnight build should survive a network blip or a brief rate limit without you having to babysit it, but it should not waste time retrying a failure that will just fail again the same way.
The mechanism. Meld retries the transient failures (a network blip, a rate limit, a memory spike) up to a couple of times, and never retries the deterministic ones (a coordinate drift, a collision, a full disk, a crash), because those need a real fix. A failed cell records a short reason so you know what happened.
How to use it. It is automatic. A red cell tells you the cause when you hover it (out of memory, disk full, rate limit, network timeout, or a crash). Resume unfinished re-queues every cell that is not merged yet, which is the crash and overnight recovery path.
Spiral build order
Why. The center of your selection is usually the part you care about most, so it should land first.
The mechanism. Meld builds cells from the center outward in a spiral, so the dense core of the world is ready before the edges, and you can open and walk the middle while the rim is still filling in.
How to use it. It is automatic. You will see the cells on the map fill in from the middle out.
Why small cells can finish faster
Why. A few big cells look like they should beat many small ones, but they usually do not.
The mechanism. A small cell builds and saves quickly, so the pool keeps every worker busy with a steady stream of light saves. A big cell holds more in memory and writes one large save burst at the end; stream to disk (automatic for cell size 8 and up) evicts finished regions as it goes, so that burst no longer runs the machine out of memory. Generation is CPU bound, so the steady cadence of many small cells often finishes sooner than a few big ones. Cell sizes are 1, 2, 4, 8, and 16 regions; 4 is the default and the sweet spot for most builds, with 8 and 16 for very large jobs where stream to disk carries them.
How to use it. Set Cell size in Settings. Start at 4. Only reach for 8 or 16 on very large areas, and let Recommend weigh it against your CPU, RAM, and disk.
Recommend settings
Why. The right cell size and worker count depend on your CPU, your RAM, and how fast your save drive is, which is hard to guess.
The mechanism. The Recommend button probes your machine (cores, memory, and save disk write speed) and suggests a cell size, worker count, and lighting setting, bounded by whichever resource is tightest. The main one is CPU: it keeps workers times threads at or under your cores, and on a big CPU it fills the machine rather than stopping at an arbitrary cap. Meld 1.8.2 removed the old fixed ceiling of 8 workers, which had left a 16-core, 32-thread machine half idle. RAM and save disk speed are secondary caps for machines with little memory or a slow drive.
How to use it. Click Recommend in the left rail, review the This PC and Recommended values, then Apply or keep your own.