Memory and Allocation

Something is keeping objects reachable, and the collector is doing its job correctly by not touching them. It does not collect objects that are still referenced; it has no way to know a reference is one you no longer want.

The usual suspects are all long-lived holders. A static collection or a singleton's field that is only ever added to. A cache with no size limit and no expiry. An event where handlers subscribe per request and never unsubscribe, so the publisher holds every subscriber that ever existed. A captured DbContext of the kind the dependency injection lesson described, accumulating tracked entities.

The pattern in the symptoms is informative. Memory that never drops overnight rules out a load-related spike, because idle time would have let a transient peak be collected. A rising floor means growth, not pressure.

Frequent collections plus growing memory is a recognisable signature. The collector keeps running, keeps finding almost nothing to reclaim because everything is reachable, and promotes survivors up the generations. Generation 2 then grows, full collections get more expensive, and that is where the gradual slowdown comes from — the memory growth and the slowdown are the same problem.

Diagnosing it means looking at what is on the heap, not at the collection counts. A memory snapshot taken an hour apart, compared by type, shows which type is growing. Then the question is which long-lived object holds those instances, and the answer is usually a static field, a cache or an event.

Three sources of allocation are worth naming. First, boxing: every decimal and int added to a List<object> becomes its own heap object. Second, string concatenation in a loop: each += creates a new string and abandons the previous one, so 300 orders produce 300 increasingly large strings. Third, the list itself, which reallocates its backing array as it grows.

The boxing and the concatenation are worth fixing, and both fixes make the code clearer rather than more obscure. A strongly typed list removes the boxing and restores compile-time checking at the same time. StringBuilder removes the intermediate strings and expresses the intent better.

Presizing the list is worth doing only when you know the count, as you do here, and it is genuinely marginal — a handful of array copies for 300 items. It is included to show the difference between an allocation that matters and one that does not.

What is not worth changing: the orders themselves, the final string, the StringBuilder. Those are allocations the work requires. Removing necessary allocations is not the goal; removing the ones that produce nothing is.

For a few hundred orders, none of this is measurable. The version to write is the second one regardless, because it is also the clearer of the two — and that is the honest reason to prefer it. If this ran per request on a busy service, the measurement would then justify it on its own terms.

// Before: boxing on every value, a new string on every iteration.
public string BuildReportBefore(IReadOnlyList<Order> orders)
{
    List<object> values = new();
    string line = "";

    foreach (Order order in orders)
    {
        values.Add(order.Reference);      // reference type, no boxing
        values.Add(order.Total);          // decimal boxed
        values.Add(order.ItemCount);      // int boxed

        line += order.Reference + "," + order.Total + ";";   // new string each time
    }

    return line;
}

// After: no boxing, one buffer, and the compiler checking the types.
public string BuildReportAfter(IReadOnlyList<Order> orders)
{
    // Capacity known up front, so the backing array is allocated once.
    List<(string Reference, decimal Total, int ItemCount)> values = new(orders.Count);
    StringBuilder line = new();

    foreach (Order order in orders)
    {
        values.Add((order.Reference, order.Total, order.ItemCount));

        line.Append(order.Reference)
            .Append(',')
            .Append(order.Total)
            .Append(';');
    }

    return line.ToString();
}