12-21-2010 04:49 PM
@SteveChandler wrote:
I looked at the code you posted but it doesn't do anything. Even if it did I need a hex encoded string and not a numeric. As I said I am sending this over the network.
I still don't understand the issues. What is on the receiving end? Is that also a LabVIEW program under your control?
How are you sending this over the network? TCP/IP only handles strings, so an array of strings is not approrpiate anyway.
What's wrong with sending the raw original string directly?
Can you tell us a bit more about your setup?
12-21-2010 05:42 PM - edited 12-21-2010 05:48 PM
Thanks altealtenbach. The code snippet is only part of it. I posted an llb halfway through this thread that contains the encode and decode vis.
There is not a problem. It works very well. I can encode and decode a 10M file in about 10 seconds. I am just wondering if someone can give me feedback on how to make it even faster. I want my network to be the bottleneck.
Django is on the other end. That is a Python web application framework. I don't think I can send a raw binary string to Apache without corruption.
But my original question - is the first code snippet the fastest way to convert a string to an array of hex characters?
12-21-2010 06:56 PM
SteveChandler wrote:But my original question - is the first code snippet the fastest way to convert a string to an array of hex characters?
Yes, I think so. The primitives are typcally higly optimized.
I tried a very quick alternative using a lookup table and it was about 2x slower.
You might be able to split the problem for parallel execution on several CPU cores, but it's probably not worth it. Most likely the network transfer is the real bottleneck.
12-21-2010 07:05 PM
Thanks!
The original string to hex vi used string concatenation in a loop. I replaced that with the files in the llb and it is much faster. The strings are sent to a queue and it was filling up sometimes using the original hex encoder. The new one keeps the queue empty most of the time. Every once in a while there are as many as twelve items in the queue now but I am thinking of the future by trying to optimize as much as I can. I might write a dll to do this.