MATLAB: Backslash (\) operator became much slower when updating from 2015b to 2019a

backslash operatorlinear systemMATLABmatrixmldivideperformance

Hello,
we recently updated our pretty old Matlab version from 2015b to 2019a, also due to hope for increased code performance.
A big simulation code of mine, which solves a lot of nonlinear (and hence also linear) systems, is now much slower than in the old 2019b version. Using the profiler, I was able to quickly find the root cause of the issue: The backslash operator, at least in my case, became slower by a factor of approximately 2.
My code is simply:
dx = -jac\f;
In my case, the matrix (called jac) is a 1438×1438 sparse matrix, the spy plot looks as follows:
spy.PNG
The vector f is a non-sparse 1438×1 vector.
Doing (repeated and averaged) timing tests with the following code:
timeit(@() -jac\f)
yields
0.0054 on Matlab 2015b, and
0.012 on Matlab 2019a.
What is going on here? Has the algorithm selection in mldivide/backslash operator changed in the recent years? How can I get back to the old performance?
Trying to reproduce the problem in a more general and simple setting, I composed the following code:
Adense = diag(ones(4e3,1));
Asparse = sparse(Adense);
b = rand(4e3,1);
Duration_dense = timeit(@() -Adense\b)
Duration_sparse = timeit(@() -Asparse\b)
On my machine, this yields for Matlab 2019b:
Duration_dense =
    0.0823
Duration_sparse =
   3.6871e-05
In Matlab 2015b, I get the following for the same code as above:
Duration_dense =
    0.0813
Duration_sparse =
   3.8327e-05
I think this proves that in both the old and new versions, sparse matrices are correctly recognized as such (anything else would have been shocking). The issue might then be related to the specific sparsity pattern of my matrix.
Does anyone have an idea what is going on here?
Thank you!

Best Answer

Thank you for these logs. The difference in behavior comes from the following message, saying that we repeat the factorization with different options:
sp\: However, UMFPACK may have failed to produce a correct factorization
     possibly due to aggressive pivot tolerances or because the problem
     is ill-conditioned.
sp\: These tolerances were:
	Pivot Tolerance:           0.1
	Diagonal Pivot Tolerance:  0.001
We will factor the matrix again but use standard partial pivoting.
This is done because we heuristically determined that it's likely for the result of the first computation not to be accurate enough. This tolerance was tightened recently, which would be why it's now showing up for this matrix.
There are parameters in spparms that can affect the behavior of the sparse LU solve ('piv_tol' and 'sym_tol') which may be changed to avoid this behavior. You could use spparms to check if this works.
Note these options will also affect the accuracy of the result, so it's a good idea to check the residual while you are modifying the parameters, and to, if possible, only use modified spparms settings in the context where you need them. These are global variables that will affect the behavior of every call to backslash in a MATLAB session.
Related Question