When is pre-sizing collections a premature or counterproductive optimization, and how would you decide where it's actually worth applying?

## The optimization and its real cost **Pre-sizing** means passing an expected capacity to a collection constructor so its backing storage is allocated once instead of growing repeatedly (see the companion questions for the mechanics). It removes the **constant-factor** overhead of grow-and-copy (ArrayList ~1.5x) and double-and-rehash (HashMap), plus the garbage those produce. Crucially it does **not** change asymptotic complexity — building a list is O(n) either way — so the win is in constant factors and **allocation/GC pressure**, not big-O. ## Why 'always pre-size' is wrong Treating pre-sizing as a universal rule misapplies effort and can backfire: 1. **Small collections:** A list that holds 3 or 30 elements resizes a handful of times at most, copying a tiny array. The cost is in the nanoseconds and utterly dominated by everything else. Adding `new ArrayList<>(30)` here buys nothing measurable. 2. **Cold paths:** Code that runs once at startup, or rarely, has no hot-loop cost to save. Optimizing it trades readability for zero throughput. 3. **Unknown size:** If you can't estimate the count, you either guess (risking a bad estimate) or you can't pre-size meaningfully. Default growth is already efficient — don't force a number. 4. **Over-estimation harms:** Sizing for the worst case when the common case is tiny allocates a large, mostly-empty array on **every** call. That wastes heap, worsens **cache locality** (a sparse big array touches more memory pages), and can create *more* GC pressure than the resizes you avoided. An over-sized `HashMap` also spreads entries across more buckets than needed. 5. **Maintenance cost:** A literal capacity is a **magic number**. If the data's typical size shifts later, the hint silently becomes wrong (too small → resizes return; too big → waste). It's one more thing to keep honest. 6. **The Knuth caveat:** 'Premature optimization is the root of all evil.' Micro-optimizing before measuring spends your attention on code that isn't the bottleneck and obscures intent. ## A decision procedure Apply pre-sizing when **all three** are true, ideally confirmed by data: - **Known/estimable size:** you have the count (e.g. `list.size()` of a source, a query row count, a batch size) or a tight upper bound. - **Large enough to matter:** thousands-plus elements, where the resize/rehash work and garbage are non-trivial. - **Hot or latency-sensitive:** the builder runs in a tight loop, per-request, or on a path with a latency SLA where GC pauses hurt. ### How to find those spots Don't guess — **measure**: - **Allocation profiling:** Java Flight Recorder (JFR), async-profiler in allocation mode, or VisualVM to see which call sites allocate the most (resizes show up as collection-internal array allocations). - **GC logs / pause analysis:** if collection churn is driving young-gen GC, the throwaway arrays from resizing are a visible contributor. - **Microbenchmarks (JMH):** to validate a specific hot builder actually improves, including warm-up so the JIT has compiled the path. ## Prefer expressive forms When you do pre-size, make intent obvious and the math safe: - `new ArrayList<>(source)` / `new ArrayList<>(expectedSize)`. - `HashMap.newHashMap(n)` / `HashSet.newHashSet(n)` (JDK 19+) instead of hand-rolling `n/0.75+1`. - A named constant or a comment explaining where the size comes from, so the 'magic number' is justified. ## Bottom line Pre-sizing is a sharp, cheap tool for the **specific** case of building a large collection of known size on a hot path. As a blanket habit it adds clutter, risks wasteful over-allocation, and distracts from real bottlenecks. Default to clear code, profile, and pre-size the few places that earn it.