A loop that allocated a column at a time

The first @time call includes compilation, so its allocations are not the loop's. The second call is the one to read. A global A allocates on its own, so pass it in as an argument. Then compare two matrix widths. A count that grows with the column count points at the loop.

liv_n's method settles it, it's the loop and not compilation. Inside a function, with A passed as an argument and only the second call read, the allocations scale with the column count without views and stop scaling with @views on the loop.

One warning for anyone tempted to move @views up to the whole function. It walks straight into the thing my own post warned about.

@views function colsums!(out, A)
    for j in axes(A, 2)
        out[j] = sum(A[:, j])
    end
    backup = A[:, 1]
    A[:, 1] .= 0
    return backup
end

backup is meant to be a copy. Under @views it's a view, so after the zeroing line it's all zeros too. The allocation numbers look great and the function returns the wrong thing. @views on the loop only, then.

There's a middle path between the loop and the whole function. Leave @views wherever it is and spell the deliberate copy as copy(A[:, 1]). Inside the macro the slice turns into a view first, and copy then builds a fresh array from it, so backup survives the zeroing. Outside the macro the same line copies once more than it needs to, which is harmless. Either way the line means the same thing to someone who later moves the macro around, and that was the part I cared about.

Then rerun the two-width comparison from liv_n's post with the macro on the whole function. One extra column-sized allocation per call should show up for the backup, and nothing that grows with the width.

Read the bytes as well as the count. If @allocated on the second call divided by the column count lands near one Float64 column, about eight bytes per row, it's the slices and nothing else.