elide more tuple allocations

[timholy]

One hope with the sampling profiler is making our code more efficient; the curse may be that it will trigger questions about things that don't actually matter.

In that spirit, I've gotten the impression that anytime a tuple is involved, there's a likelihood of triggering the garbage collector. It's interesting to run the sampling profiler on the following function:

function myfunc(B::Matrix, n::Int)
    local C
    for i = 1:n
        C = chold(B)
    end
    C
end
A = randn(20, 40);
B = A*A';
@sprofile myfunc(B, 200000)

A large fraction of the samples are taken inside the garbage collector. But at least on my machine, they're not where I expected: they seem to occur inside chkstride1.

I can eliminate many of these "weird" garbage collection events by defining additional functions:

function chkstride1(A::StridedVecOrMat)
    if stride(A,1) != 1
        error("LAPACK: Matrix must have contiguous columns")
    end
end
function chksquare(A::Matrix)
    if size(A, 1) != size(A, 2)
        error("LAPACK: Matrix must be square")
    end
end

Then there are still plenty of garbage collection events (so I think this doesn't change performance), but this time they're in a place that seems to make more sense, jl_alloc_array_1d.

If we get to a point where we can re-use memory in assignments, I wonder if the tuple behavior will become a source of trouble?

I'm asking this in part because I noticed, long ago, that gc was the main bottleneck for the Grid module. At the time, I found this very weird because I designed it to do as little memory allocation as possible. I haven't had time to follow this up recently, however.

Anyway, it was something I found curious, and felt I'd ask about it.

[JeffBezanson]

These profiling investigations promise to be very helpful.
All I can say is tuples are heap-allocated, and so can cause GC, no more or less than anything else. We need more tricks in the compiler to elide tuple allocations.

[dmbates]

I was probably getting too cute when writing the chkstride and chksquare functions. Having looked at other code, which I believe was written by Jeff, I think that more liberal use of assert() is the better path. I just got tired of writing

if (stride(A,1) != 1) error("Matrix X must have contiguous columns") end
if (stride(B,1) != 1) ...

[JeffBezanson]

assert is great but it shouldn't be used for user-facing errors. An assertion failure means there is a bug in the code containing the assertion.

[toivoh]

I submitted a pull request a while back with a corresponding @expect macro for user-facing errors, but there didn't seem to be much interest. Or are you saying that user-facing errors should be more informative as well? (a good thing to strive for, of course)

[johnmyleswhite]

I believe there's a push towards pushing more typed errors forward for handling errors programmatically.

[toivoh]

That would be nice, but seems to go against the decision not to have typed catch clauses?

[timholy]

I would say that informative is good.

If there's no bug that's triggering excess gc, I'll close this. The issue of reducing temporaries/gc will surely be up front-and-center in future optimization efforts.

[timholy]

Oops, from the fact that someone changed the title, it seems this is better left open. Reopening.

[JeffBezanson]

Dup of #2496 .