Growth factor 2x or 1.5x for a buffer in a service with a hard memory cap — how do you decide?

## Why this is a judgment call and not a lookup Both 2 and 1.5 are constant factors greater than one, so both give amortized constant appends and a logarithmic number of growths. Asymptotic analysis cannot separate them — it deliberately discards exactly the constants the question is about. The decision is made on memory behaviour, latency shape, and what the organisation can maintain. ## The transient peak: the thing that actually breaks a memory cap During a growth the structure holds two blocks at once: the old one it is copying out of and the new one it is copying into. It cannot release the old block until the copy finishes. So at that instant, for a buffer holding n elements at full capacity: | Factor | Old block | New block | Live at the moment of copy | |---|---|---|---| | 2.0 | n | 2n | ~3n slots | | 1.5 | n | 1.5n | ~2.5n slots | A hard resident-memory cap is enforced against the peak, not the average. A service that comfortably holds 4 GB of records steady-state can be terminated by the 12 GB instant that a 2x growth creates. This is the single most important line of the argument, and it is the one candidates most often skip past on their way to counting copies. ## The reuse argument, stated precisely and with its caveat Work in units of the original block. After several growths the buffer is using a block of size rᵏ, and the blocks it has already released have sizes 1, r, r², …, rᵏ⁻¹, summing to (rᵏ − 1)/(r − 1), which for large k is about rᵏ/(r − 1). The next block it will ask for has size rᵏ⁺¹. For the released run to be able to hold that request you need rᵏ/(r − 1) ≥ rᵏ⁺¹, which simplifies to r² − r − 1 ≤ 0, that is r no greater than the golden ratio, about 1.618. - At **1.5**, that inequality holds (2.25 < 2.5): the previously freed blocks, if they are adjacent and coalescible, can eventually accommodate a later allocation. The buffer can walk back over its own footprint instead of marching forward through the address space. - At **2.0**, each new request is strictly larger than the sum of every block freed before it, so it can *never* fit in the freed run. The buffer's footprint always advances into new territory. The caveat matters as much as the result: this argument assumes the freed blocks are contiguous, that the allocator coalesces them, and that nothing else was allocated in between. In a real service with many allocation sites, size-class allocators, and blocks large enough to be mapped directly from the operating system and returned on release, the effect ranges from decisive to entirely absent. Present it as the *reason* the smaller factor exists, and then say you would measure whether it materialises here. ## What 1.5x costs you Be honest about the other side or the answer is advocacy, not judgment: - **More growth events.** Reaching a given size takes about 1.7x as many growths at 1.5 as at 2 (log base 1.5 versus log base 2). - **More total copying.** Over the buffer's life, roughly twice as many element copies at 1.5 as at 2. On a throughput-bound batch job that is real time lost. - **Less slack, which cuts both ways.** Immediately after a growth, unused capacity is (r−1)/r of the block: 50% at 2x, 33% at 1.5x. Lower waste is the point under a cap, but it also means the buffer refills sooner. ## How I would actually decide 1. **Name the binding constraint.** A hard RSS cap on a fleet where termination is the failure mode is a memory-shaped problem: the smaller factor, and the peak calculation above, wins. A batch job that is throughput-bound with memory to spare is a copy-shaped problem: the larger factor wins. 2. **Question the shape before tuning the knob.** Under a hard cap, an unbounded contiguous buffer is a strange thing to own at all. A bounded buffer with backpressure, a flush at a fixed record count, or fixed-size blocks all give a *predictable* ceiling rather than a factor that merely makes exceeding it less likely. Choosing between 2 and 1.5 optimises within a design that may itself be the problem. 3. **Pre-size where an upper bound is genuinely known**, and treat the reserve as an optimisation rather than a guarantee — if the estimate comes in low the growth behaviour returns, from a larger base. 4. **Weigh the maintenance cost.** A custom growth policy is a knob nobody remembers exists, invisible in review and unexplained in six months. If the win is not measurable on your workload, the default is the better engineering answer, and "we measured and it did not matter" is a legitimate outcome to report. 5. **Measure the peak, not the mean.** Instrument resident memory at high resolution, or the cap will be exceeded by a spike your averaged dashboard never shows. ## The failure mode to avoid Arguing the factor from what some library happens to do, or from a general belief that "doubling is standard." Different mainstream standard libraries settled on visibly different factors, and both survive, which is the strongest available evidence that the choice belongs to the workload rather than to the structure.