LAPACK wrappers: use resize!(a) instead of a = Vector{T}()

[alyst]

Following up the discussion at #21564, replace a = Vector{T}(n) with resize!(a, n).
Hopefully should decrease resources usage by a tiny bit.

Also add comments clarifying why BLAS routine is called twice.

[ararslan]

Dunno how visible this will be to the Base benchmarks, but...

@nanosoldier runbenchmarks(ALL, vs=":master")

[Sacha0]

Why change from a zero-dimensional Array to a single-element one-dimensional Array? Ah, I see rwork was formerly bound to a fresh Vector below, and you now resize instead. 👍

[tkelman]

this commit should probably be squashed, on merge if not before

[Sacha0]

Thanks @alyst! :) (Absent objections, requests for time, or someone beating me to it, I plan to merge this tomorrow morning.)

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[ararslan]

Those benchmarks are a little surprising given that the intent of the PR is to reduce memory usage.

[alyst]

Oh, well. Maybe resize!(A, n) is a little bit eager than Vector(n) and allocates a little bit more than requested (and more than the ctor)?
It calls jl_array_grow_end() internally. Maybe there's way to be more precise.

[alyst]

It looks, though, that time-wise these linalg benchmarks are much more precise than their tolerance values: all changes are within 3%.
FWIW, there's 11 that are "faster" and only 2 that are "slower" :)

[ararslan]

@nanosoldier runbenchmarks(ALL, vs=":master")

[fredrikekre]

Last commit (change of array growth) seems like a change for another PR? Ref #8269 and #16305

[alyst]

@fredrikekre Absolutely. Just a wild guess. OTOH it shouldn't be as disruptive as the change of the growth rate.

[alyst]

Funnily, Travis failed in the QR test, but the problem is not in the linalg. Most likely the last commit exposed something in string interpolation.
The errors come from test/lq.jl:

lstring = sprint(show,l)
qstring = sprint(show,q)
@test sprint(show,lqa) == "$(typeof(lqa)) with factors L and Q:\n$lstring\n$qstring"

The difference between LHS and RHS is the last lstring char. In one of the failing tests LHS contains -0.0824939+0.344439im]\nComplex{Float64}[, whereas RHS fragment is -0.0824939+0.344439im\x01\nComplex{Float64}[.

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[alyst]

Surprisingly, the benchmarks had not regressed memory-wise except join(string) (and I would not call join(string) a regression, because the memory allocation very much depends on the lengths of concrete strings being joined).
The LAPACK memory regressions are gone.
Could we ask nanosoldier to run the benchmarks once again to be more sure about time-wise changes?

[KristofferC]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels

[nalimilan]

While this heuristic doesn't sound absurd to me, maybe it would make sense (as in more robust) to add an exact=false argument to resize!?

[alyst]

I think giving the user more control over memory allocation, resize!() in particular, would make a lot of sense. Unfortunately, I didn't expect that trivial LAPACK fixes would require that sort of things: the last commit was just a quick check. I'd rather way until the memory allocation problem is addressed by a separate PR and update this one accordingly.

[andreasnoack]

I think we should just merge the lapack wrapper part of this PR. The wrappers will use slightly more memory for now but it still looked like it gave a speedup. Probably because the wrapper then interacts less with the GC. We might be able to make resize! later, but that can be done in a separate PR.

[alyst]

@andreasnoack I've moved the last commit into the new issue for discussions.

[alyst]

#22038 is merged, so this one should not introduce regressions when merged into master.

[ararslan]

@nanosoldier runbenchmarks(ALL, vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @jrevels