Interesting code benchmark issue

[scofield]

Hello All,

I was working on benchmarking a subVI which is used to count the number of occurrences of a (sub)string in another (main)string.

For example, in aAbBcCdDabc (main)string, there are 2 occurrences of a (sub)string or 1 occurrence of Bc (sub)string.

I added a Diagram Disable Structure (DDS) and implemented the same functionality in a different way.

Later I realized that if I use a DDS and enabled the new implementation, it seems to be executing way slower than if I remove the DDS (with new implementation code only). On the other hand whether or not I use DDS, the original implementation takes almost same time to execute.

Looking forward for your comments.

[cbutcher]

Hi scofield,

I'm not sure, but at a guess - if you remove the DDS, then LabVIEW optimizes the second method by noticing that the inputs are constant, and so just caches the result and uses something like the equivalent of Initialize Array to produce the appropriate output.

I'd guess that the more complicated "initial method" can't be recognised by the compiler to follow this pattern, so it actually does calculate the result 100000 times (per test).

I suspect the behaviour with the DDS is something like that it prevents this optimization - so the initial method (with While loop) may be 2-3x as fast (on my computer) as the Search and Replace, and when LabVIEW actually performs the S/Replace 100000 times, it takes longer than the While loop version. Reducing by a factor of 100k eliminates the 2-3x factor from being measured/noticed.

But that's just my guess 🙂

[crossrulz]

Considering there are no actual outputs, I would expect the entire inner FOR loop to be removed.  At least it would if debugging were turned off.  Speaking of debugging, that is likely why the DDS increases your time.  It is creating more places that can be probed, so a lot more code is needed to handle the structure boundaries and the associated tunnels.