Performance of Integer to Hex-string array

[Ton Plomp]

I was looking at a function to format a binary string as hex, and tried to get some performance.

I was shocked with the following results:

What i've concluded is that the Integer to Hex-string function for arrays is not working with U8's but with something else (U32's?).

Ton

[asbo]

What's your OS? I'll run LV2009 and LV2010 on Win7 x64 if you backsave the VI.

[Saverio]

This may be due to the coercion dot, as reported here: http://forums.ni.com/t5/BreakPoint/Monthly-bugs-August-2008/m-p/758921?view=by_date_ascending#M6325.

It appears to still be there, though I don't recall if this was ever determined to be an actual problem.

[Ravi Beniwal]

This may be due to the coercion dot, as reported here: http://forums.ni.com...scending#M6325.

It appears to still be there, though I don't recall if this was ever determined to be an actual problem.

In the case of the For Loop, when the string is converted to a U8 array, some memory was claimed, which would cost some time. Including this time, this case completed within 1391ms. Now in the int to string case, we can think of the coercion as claiming another same size memory location with its added time cost. So wouldn't we see more like twice the time it took for the first case instead of about 13 times?

[Darin]

I seem to remember that Floats are coerced to 64 bit integers, so I am guessing that the default input type is U64 for arrays. It seems silly to not have an explicit [u8] input for the primitive instead of blowing up [u8] to [u64].

I am curious if you could check the performance with different integer array types and find one with a smaller time differential between the two methods.

A very useful rule-of-thumb for optimization is that the more code you push into a primitive, the faster it will be. This bug(?) breaks that rule so it is very annoying on many levels.

[Darin]

Very interesting results from some quick testing. The first time I run the test the Array method is as fast or faster than the for loop. For all subsequent tests the For Loop is much faster (10X). Ctrl-Run then the array wins the first race again.

[Phillip Brooks]

Very interesting results from some quick testing. The first time I run the test the Array method is as fast or faster than the for loop. For all subsequent tests the For Loop is much faster (10X). Ctrl-Run then the array wins the first race again.

This sounds like a development environment issue. Might a compiled version behave differently? (still using LV 8.6 )

[Darin]

Rewrote from scratch in LV9 (used native timing instead of OpenG). Array version now beats For Loop consistently by a healthy 20-50% margin. All is right with my world again, other than the annoying red dot. Same in LV10.

Slightly puzzled by the initial results matching Ton's, I'll chalk it up to bad luck. I do not know if it matters here or not, but I tend to avoid wiring indicators inside a frame I am trying to benchmark.

[Ton Plomp]

So you mean that the FP-update is the real killer?

That would be very strange. Notice that I took a file of 5.5 Megabytes resulting in an array of 5.5 Million Elements, since a single string char is 5 bytes, the total array would be 27.5 Megabytes, with the resulting string being 11 Megabytes.

I had the same results in 2010 though.

It might be that the size of the input file is important.

Ton

[Matt W]

If you make sure the indicators are updated after the benchmark (run their wires through all the remaining sequence frames) then array will win, with your current bench mark the winner will depend on which test is run first (I suspect the difference is due to pressure on the memory allocator). Personally I use also use an always copy node to copy any input data before entering it into the first sequence frame to make sure I'm not measuring a data copy (just wiring into the first frame maybe sufficient but I like being sure). That wont matter in this case since you're not modifying the U8 array.

A couple side comments. A string to U8 array can be done in place so that it doesn't take any time (a u8 array and string have identical structures in memory so LabVIEW just has to reinterpret the data)

You're greatly underestimating the size of the string array.

Each string takes 6 bytes 4 for size 2 for data.

An array of strings is an array of handles.

4 bytes (array size)+5.5 million * (4 bytes [string handle]+4bytes[string pointer]+6 bytes [the string itself] ) so a total of ~ 73.4 mebibytes. In 64bit the handles and pointers would double in size, I'm unsure if the sizes would double or not.

If you avoid the string array (and it's 5.5 million allocations) things go much faster

On the first run with 5.5 million elements I get

For Loop: 4725

Array: 2758

Mine: 134

On the second run (where LabVIEW can reuse the large arrays allocated in the first run).

For Loop: 2262

Array: 2279

Mine: 127

[Darin]

I like the direction Matt was headed, but I tend to find Case Structures a bit slow in tight loops so I would probably have done something like this instead. Over 4x faster than the built-in primitive (not often we can do that!). I suggest a new set of OpenG VIs to implement Integer Array to Hex String. I would simply use Split Number and the same lookup table for U16 and U32, etc.