However, SLOC is a poor metric for the quality of a codebase, especially scientific ones. I've certainly found many instances where longer line counts are more performant, for instance with hand-unrolling loops (very rare edge case, not suggesting doing this as a rule!).
Unless you intend to become involved in development of the library, I see no reason you would care about the lines of code. Even at that point, design philosophy, features, etc. are more likely to be major factors in your choice.
FYI: Computational Scientist here. I am neither affiliated with Blaze nor Eigen.
.. Unless it's written in a completely uncomprehensible way of course (such as some meta c++ stuff), but in languages with good metaprogramming.
In a decade of work in hpc and computational science, I have very seldom found looking at the code to be a useful tool for either verification or debugging.
Instead, use the scientific method: hypothesis testing by constructing simple examples with known analytic solutions and using that for clues as to where the real problem lies.
I like your world. Let's live there. :)
A common example is matrix multiply. For smaller matrices it's faster to use naive O(n^3) multiply because of the large constant factor with Strassen's algorithm. At some point n^3 will dominate the constant factor, and Strassen's becomes better. To get the best performance in all cases, both algorithms need to be implemented, which increases the code size.