You'll probably need to test this out for yourself for your own particular class of problems and dataset sizes.
I've only dabbled with Matlab a little over the last few years so my impressions may be a bit stale, but here goes anyway:
1. LabVIEW with NI cards is far and away a nicer environment for pulling real-life signals into program data and pushing data out as real-world signals.
2. Some built-in Matlab functions are impressively fast on really big datasets. My impression was that Matlab seemed more likely to be closer to best-in-class implementations of algorithms. It stands to reason since Matlab is pretty much all about the number-crunching. LabVIEW has improved noticeably over the years though and may not lag much, if any, these days.
When I first started using LabVIEW, I would typically collect a big dataset, throw it onto a Zip disk (100 MB oversized floppy circa 1997), then do all the post-processing at my desk in Matlab. In the last few years, the only time I did something like that was because I needed to deliver the Matlab processing script to a colleague who had Matlab but not LabVIEW. Without doing side-by-side comparisons, I simply don't find the speed of LabVIEW data processing to be any kind of bottleneck.
3. The speed of a custom Matlab script is highly variable. Code that can be "vectorized" can run almost magically fast. Code that must loop a million iterations through the script interpreter can be dog slow, to the tune of 2-3+ orders of magnitude. Labview algorithms will always run as compiled code which would put them much nearer to the "vectorized" Matlab code than the interpreted script. Could even beat the Matlab code in many cases, I'd expect. Check on some of the "coding challenges" here on ni.com -- several demonstrate impressively fast algorithms implemented in LabVIEW. The Mathworks site has even more, far more nicely presented contests. (Personally, I favor the open-source collaborative nature of the Matlab contest, building one's solution using the best features out of prior entries.
4. If the processing speed requirement has to do with generating outputs as a real-time response to inputs, then the algorithm speed alone won't be the only factor. The real-time platform and environment, including signal I/O, may also be a big consideration. Using LabVIEW RT does require a bit different mindset than LabVIEW on Windows, but there aren't any real drastic departures. Having used RT, I find that its lessons are usually helpful on Windows as well. I can't comment on Matlab's real-time toolkits/environment/hardware, etc.
Benchmark results often depend heavily on the nature of the benchmark being used and aren't always reliable predictors of normal real-life use. If you can describe your app in more detail, folks may be able to offer better tips. My own bias is that just about anytime there's a wire connecting my computer to a real-world signal, I pretty much assume I'll be using LabVIEW to deal with it. I do however recognize the strengths of Matlab & Simulink. I've made LV functions to help me do things similar to "data[find(data > threshold)] = NaN;" but it isn't nearly as elegant as the Matlab script.
-Kevin P.
ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
