Binary Parsing - Which method is faster - CHALLENGE

[DailyDose]

I'm currently working on a parser that has a ton of real time data it needs to parse.  There's a section in the data where the U8 is broken up into booleans.  For just a few data packets, the methodology wouldn't matter.  But with a ton of data, time is of the essence.  So I built this VI to test two methods of parsing to determine which method is faster.  I think (I THINK) I made the race fair.  I had to rebuild it a couple times.  Kept running into the randomness of LabVIEW which was making the race unfair.  Take a look.  Make a guess at which method you think will be faster then run it.

The challenge - see if you can make it faster.  I really am curious if there's a more efficient/faster way to do this.  The VI is in LabVIEW 2020 SP1. (I've added the VI and an image of it.)

[raphschru]

This is 33% faster than solution B:

I think the for loop is optimized to not make reallocations if the same array is indexed in and out of the loop…

[LVNinja]

from what I could observe, it looks like the most time consuming is converting from U8 into Boolean cluster/array. 

You may consider converting from Boolean into Number and parsing numbers instead. 

[billko]

---

@raphschru wrote:

This is 33% faster than solution B:

I think the for loop is optimized to not make reallocations if the same array is indexed in and out of the loop…

---

I'm guessing everything will beat method A because of the extra step of indexing the Boolean array.  Ordinarily I might choose method A because of code clarity (you can easily see a miswired bit, not so easy to see that you ANDed the wrong value), but where speed is king, bitwise operations rule.

[mcduff]

This mod of Solution A is faster on my computer

[DailyDose]

---

@raphschru wrote:

This is 33% faster than solution B:

I think the for loop is optimized to not make reallocations if the same array is indexed in and out of the loop…

---

Now that's interesting. I thought for sure any amount of "rebuilding arrays" would cause noticeably slower parsing times.  That adjusting a pre-initialized array was faster.  Now I have to rethink how I'm doing the rest of my parser...

[DailyDose]

---

@mcduff wrote:

This mod of Solution A is faster on my computer

---

But this will produce 8 boolean, yes?  Which later you must then dig out only the 6.

[altenbach]

Unless we gain a factor of two, it is not worth bothering.

I would keep it simple:

EDIT: Sorry, I got a phone call and did not see the later responses suggesting the same. And yes, a LUT would probably work better.

[mcduff]

---

@DailyDose wrote:

---

---

But this will produce 8 boolean, yes?  Which later you must then dig out only the 6.

---

Don't understand the question. Your VI used only 6 booleans, if you want all 8 right click and change the array to cluster size. (This picks out the first 6 booleans in the array.) The main limitation is that you can't specify just the middle booleans, only from beginning to end.

[BertMcMahan]

Pre-generating a lookup table array seems to beat Solution B (as-posted) by about 2x:

No need to convert the same U8 value to the same boolean array more than once. This was quick and dirty so there may be more gains to be had with array indexing, etc. in the second loop but I tried to keep it as "apples to apples" as possible. Note that this was also faster than using a Map with a U8 key.

I was also able to get another ~2x speed gain by enabling parallelism in the second For loop.