LabVIEW2012 has long execution time to write string than LabVIEW2011 on XP SP3

[ELI2011]

Remove the bottom loop and replace with "High Resolution Relative Seconds.vi" to calculate the execution time, almost the same problem as before, the execution time is about 144 seconds on English XP, after change the OS language back to Chinese, the execution time is about 300 seconds again. 

If the front panel sluggish or has overlapping elements, this issue should not only occurs on Chinese XP. We seem beside the point.

Is there a character conversion delay on Chinese XP OS?

[altenbach]

Is there anything preventing you from actually attaching the test VI as well as the subVI? 144s is a very long time. How many elements are in the input array? What is the average element size?

You might also look into your unicode settings. Start reading here.

[ELI2011]

No.

A total of 318 commands in the input array.

The average commands size is only about 100 letters, but some commands will cause the DUT output a large size of string that maybe 160kB (about 166860 letters).

If remove the wire between front panel indicator and output of "Script Execute Instr" in block diagram, the execution time will be about 145s on Chinese XP OS;

[altenbach]

Unless you attach your test VI (incl subVI), we probably cannot help you further. Even with large strings, things should be much faster.

What happens inside the subVI? Does the subVI communicate with a device? If so, how?

[ELI2011]

Does the subVI communicate with a device? If so, how?

Eli: Yes, this test program used to test the cable modem, we use telnet login the modem and enter commands to driver the CPU to execute function test.

In the attached sample code, there are three for loop, the 1st and 3rd loop only write small size string, while the 2nd loop write large size string (about 160kB).

the contoller "execute cycle" on front panel allow you add large size string to indicator "Console"

1. if set the "execute cycle" to 0, that only show small size string, then execution time is only about 0.8s;

2. set it to 1, you can see the 3rd loop execute little slow, and execution time is about 8.4s;

3. ......

4. set it to 3, you can see the 3rd loop execute much slow, and execution time is about 24.5s;

remove the console property in the 2nd & 3rd loop, and set "execute cycle" to 3, the execution time is only 0.8s again;

p.s source code with LabVIEW 2012 works on Chinese XP SP3 OS;

[altenbach]

If you write to a local variable of the string instead of a value property node and set the scroll position at a lower rate asynchronously, the entire thing executes in about 20ms (with all the wait removed and execution cycles set to 10).

See attached example modification.

(Still, the string could grow without bounds in the real application, so you might want to limit tie size in some way.)

[ELI2011]

I have just realize that this example code cannot fully represent my test program code.

Your way is really efficient on the sample code, but my test program still has the issue after using a local variable of the string instead of a value property node. 

It only save 30 seconds with local variable. But if I remove both local variable and value property (do not write front panel indicator), the execution time is back to normal, that is about 140s.

[altenbach]

Why does the subVI need the full historic string with each call? Can you show us the actual subVI?

[ELI2011]

The code need to execute with our device, or it can't run a step, do you want it?

[altenbach]

I want to look at it. Again, why do you pipe the entire historic string through it?