Цикл, который выделял память на каждый столбец

Первый вызов @time включает компиляцию, поэтому его выделения памяти не относятся к циклу. Читать нужно второй вызов. Глобальная A выделяет память сама по себе, поэтому передавайте её аргументом. Затем сравните две ширины матрицы. Число выделений, растущее вместе с числом столбцов, указывает на цикл.

Метод liv_n всё решает, дело в цикле, а не в компиляции. Внутри функции, когда A передаётся аргументом и смотришь только второй вызов, без представлений выделения растут с числом столбцов, а с @views на цикле перестают расти.

Одно предупреждение для тех, кому захочется поднять @views на всю функцию. Это ровно то, о чём я предупреждал в своём посте.

@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 должен быть копией. Под @views это представление, так что после строки с обнулением он тоже весь из нулей. Цифры по выделениям выглядят отлично, а функция возвращает не то. Так что @views только на цикл.

Между циклом и целой функцией есть промежуточный вариант. @views оставить там, где он стоит, а намеренную копию записать как copy(A[:, 1]). Внутри макроса срез сначала становится представлением, и copy строит из него новый массив, так что backup переживает обнуление. Вне макроса та же строка копирует на один раз больше, чем нужно, и это безвредно. В обоих случаях смысл строки не меняется, если кто-то потом перенесёт макрос, и меня волновало именно это.

Дальше стоит повторить сравнение двух ширин из сообщения liv_n, уже с макросом на всей функции. Должно появиться одно лишнее выделение размером со столбец на вызов, для копии, и ничего, что растёт с шириной.

Смотрите не только на число выделений, но и на байты. Если @allocated второго вызова, делённое на число столбцов, близко к одному столбцу Float64, примерно восемь байт на строку, то дело в срезах и больше ни в чём.