Jump to content

Performance of Integer to Hex-string array


Ton Plomp

Recommended Posts

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?

Link to comment

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.

  • Like 1
Link to comment

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 :( )

Link to comment

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.

Link to comment

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

Link to comment

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.

post-26690-0-20988700-1317667356.png

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.