Concatenating string and putting in shift register slows computer down

[pgaastra]

Hi all,

I was trying to create a record of comms between LabVIEW and an Arduino by concatenating the current message with previous messages and putting it in a shift register.  After a couple of hours the LabVIEW started to crawl.

I had a vague idea that you could write to a string indicator without wiping the old contents.  I thought if I could do that there would not be a huge overhead copying an every larger string.  

Am I dreaming?

Thanks

[crossrulz]

Strings act a lot like arrays.  Every time you concatinate to your string, LabVIEW has to allocate more memory.  And when the string gets long, this can take a long time and slow down your system.

You really should think about limiting the amount of data is saved in your string.

[JÞB · Accepted solution]

If you need the whole comm record I would suggest streaming the comms to file.  Make sure you put a boolean in to disable logging.

Usually, this is one of those things you only do while debugging.  If so use NI Spy rather than write your own debugger.

[Norbert_B]

Also, let it run some hours longer and you will receive out-of-memory errors and your application will stop working.

This is well-known issue for ALL programming languages and is created by growing arrays, hence memory consumption, and often referred to by the term "issue caused by memory fragmentation".

Norbert

[pgaastra]

Thanks Jeff,

I have never used NI Spy but sounds like the way to go.

[pgaastra]

Hard to see the wood for the trees in NI I/O Trace (was NI Spy).  If I need the log I think I'll save the messages to a file (Jeff's other suggestion)

Thanks again

[JÞB]

---

@pgaastra wrote:

Hard to see the wood for the trees in NI I/O Trace (was NI Spy).  If I need the log I think I'll save the messages to a file (Jeff's other suggestion)

Thanks again

---

IO Trace (NI Spy)  There I go dating myself again  I still sometimes "Dial" a telephone number too.

[tst]

Another option is to use an array of strings instead of a single string. This won't prevent the memory filling up eventually, but there is one crucial difference - with a string, LV (and the OS) has to allocate a contiguous block of memory for the string, which can be harder and harder to find as it grows. An array of string will still require the same amount of memory (more, actually - 8 or 12 additional bytes for each string), but that should be fragmented, because it should be represented as an array of pointers to where the actual strings are. Here's the relevant section from the help - http://zone.ni.com/reference/en-XX/help/371361K-01/lvconcepts/how_labview_stores_data_in_memory/