In THIS THREAD, Rolf suggested that the TypeCast primitive should have an endianness selector.
So, I took the code that I created above and slapped a byte order input on it!
Of course, this isn't as flexible as the real primitive. But this fills a wide use-case from a project that I'm working on.
Why is this interesting to me?:
On more than one occasion now, I've run into situations where I have to receive a stream of bytes at high rate over the network, and TypeCast these into LabVIEW numerics.
and usually when this happens, I'm getting those bytes sent to me in little-endian order. Because that's what dominates the industry these days it seems.
I use the TypeCast primitive to convert the byte stream into numerics, but this means that I have to reverse array order before handing the data over to TypeCast.
And then, depressingly, TypeCast performs another set of byte swapping against the data.
So, I was hoping to remove all the byte swap operations with this VIM.
I plugged my VIM into the benchmark tester, and the results seem to make really good sense to me:
1 = My VIM with "Big Endian" input --> My VIM must perform array reversing; this makes it slower than all other methods thus far.
2 = My VIM with "Little Endian" input --> My VIM does not have to perform array reversing; This makes it almost as fast as MoveBlock with preallocation.
Would love to know what you guys think
TypeCast.zip