LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Number to hexadecimal string memory allocations

Solved!
Go to solution

 


@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?

0 Kudos
Message 11 of 14
(546 Views)

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?

=====================
LabVIEW 2012


0 Kudos
Message 12 of 14
(535 Views)
Solution
Accepted by topic author SteveChandler

 


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.

Message 13 of 14
(511 Views)

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.

=====================
LabVIEW 2012


0 Kudos
Message 14 of 14
(508 Views)