Computational Speed of MLDIVIDE When Called From MEX Function

Has anyone ever seen significant performance reduction on

x = A \ b

when A is created in a mexFunction using mxCreateSparse and filling in the Ir, Jc, and Pr arrays?

The reason I ask is that I'm using mexCallMATLAB to invoke mldivide on a moderately sized system (about 416,000 unknowns, 1.63 million non-zeros) and there is about a factor of 3.5 difference in computational speed (35 seconds vs. 10 seconds) in calling mldivide from MEX rather than directly from within the MATLAB environment.

Moreover, if I replace the direct call to mldivide with a call to a simple wrapper that does

[i, j, v] = find(A);
x = sparse(i, j, v) \ b;

I recover MATLAB's "inline" 10 second run-time and produce the same numerical solution (relative difference in the order of eps). I am quite probably doing something wrong and/or unusual in my mexFunction that's causing the slowdown, but I can't think of anything obvious. I have verified that the row indices appear in sorted (ascending) order within each column.

Any hints, explanations or suggestions would be greatly appreciated.

[James Tursa]

Can you post your code, or a reduced version of your code, that does this?

[Bård Skaflestad]

Sorry, I don't quite understand what you're asking. In particular, what is "this"?

Do you mean a copy of the code that sets up the system of simultaneous linear equations or the mexFunction that calls mldivide?

I'm afraid the first is a bit of mouthful (with some parts regrettably proprietary)

[James Tursa]

I was asking for the code that built the sparse matrix. But if that is proprietary then nevermind. I will make some tests tomorrow to see if there is a big difference on my versions. What version of MATLAB are you running?

You might try running SPOK on it to see if there is anything amiss:

http://www.mathworks.com/matlabcentral/fileexchange/20186-spok--checks-if-a-matlab-sparse-matrix-is-ok

*** EDIT ***

spok has been removed from the FEX. You can use my replacement function sarek instead:

https://www.mathworks.com/matlabcentral/fileexchange/158161-sarek-sparse-analyzer-real-et-komplex?s_tid=srchtitle

[Bård Skaflestad]

> I was asking for the code that built the sparse matrix.

Ah, right. Like I said, part of that is proprietary and in any case, it runs into a couple of thousand lines of code all included. If it helps, I can share the actual matrix and right-hand side.

> What version of MATLAB are you running?

In this case, R2014b. I haven't tried 2015a.

> You might try running SPOK on it to see if there is anything amiss

Thank you for the tip. I'll do that!

[Bård Skaflestad]

> You might try running SPOK on it to see if there is anything amiss

That turned out to be fantastically useful advice. Thank you so much, James.

My matrix had about 1.6 million explicit zero entries, which spok helpfully pointed out. I was using a static sparsity pattern derived from the connection structure of the underlying grid. The entries are structurally non-zero, but in any given problem some of them will be zero.

Removing the zero entries before calling mldivide recovers the expected runtime. My initial suspicion that I was doing something wrong was therefore confirmed and this naturally also explains why the find call cured the problem.