Showing results for 
Search instead for 
Did you mean: 

Design challenge: find biggest block of true in boolean array

Hi dear LabVIEW experts,


with the VI below I'm finding the biggest block of consecutive true elements in a boolean array.

But as this will be performed on thousands of arrays which will have 2 to 3 million elements each, I can't help but think: There must be a better implementation. 🙂


Could you please point me in the direction of a better way to do this? Some neat trick I haven't thought of myself yet?


Regards Florian

0 Kudos
Message 1 of 37

Hi Florian,


here's a different approach:



- find block and calc length of current block

- compare with stored results (length) and take new values, if bigger block is found


Best regards,

using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 2 of 37



thanks for that suggestion!

It's a good idea to do it all within the loop - sometimes I just miss the obvious.

I've put our solutions into a benchmark vi. Yours is faster than mine 2,23 ms vs. 2,65 ms per array. I made some modifications to your code because it showed different results.

I've also added a 2nd idea of mine - but it really sucks 36,93 ms!

I must say that I originally thought my 2nd implementation would be slower, but I really wanted to know for sure. 🙂


Any other suggestions? Anyone?


Regards Florian

0 Kudos
Message 3 of 37

Gerd's solution has a very slight error in calculating the size of the block. Missing a +1.


Here's another variation. Runs about the same as the others in terms of speed.


Message 4 of 37

Thanks for posting,


but I'm afraid I introduced that bug into Gerds code Smiley Sad

Sorry about that - fixed it.


Both of your snippets look pretty lean. I doubt much improvement could be made.

I was hoping for some "trick" though Smiley Wink

altenbach? Smiley Happy


Regards Florians

0 Kudos
Message 5 of 37

@Florian.Ludwig wrote:

I was hoping for some "trick" though Smiley Wink


Challenge Accepted!

Find Max Occurence.png

Software is never really finished, it's just an acceptable level of broken
Message 6 of 37



this really saves a lot of diagram space!

It is similar to my 2nd idea - but the execution is better.

On my machine it is ten times slower than the two earlier posts by GerdW and smercurio though.


Regards Florian

0 Kudos
Message 7 of 37

The reason why it's slower is because it forces you to iterate through all of the array elements. Gerd's and my solution don't do that. They only loop for as many "blocks" that you have. I believe your example array had 3 blocks, so the loops only run that many times, which is way smaller than 2,000,000.


A good example of why smaller diagram code does not necessarily equate to faster or more memory efficient code. In fact the code also creates another array of 2,000,000 elements (of integers).

Message 8 of 37



you are of cause right smercurio. That's exactly the reason why I expected my second approach and JW-L3CE's to be slower.


The trick I was hoping for would not use a loop at all I guess. I remember the time when I learned that many operations can be performed on arrays without looping through the data.

I was hoping for a similar eye opener like back then. Ahhh the good old days Smiley Happy


Regards Florian

0 Kudos
Message 9 of 37

@smercurio_fc wrote:

Gerd's solution has a very slight error in calculating the size of the block. Missing a +1.


Here's another variation. Runs about the same as the others in terms of speed.


I would probably only keep the largest size and it's index in a shift register. building large arrays at the loop boundary just to later throw away everything except one element each seems expensive.

0 Kudos
Message 10 of 37