Why does LabVIEW take significantly longer to display a large amount of Chineese characters? (intentionally misspelled)

[ToeCutter]

2000 characters is nothing- the CPU load for conversion should be imperceptible- as in over before you realise it has begun.

Perhaps there's a difference in the character display code and the unicode version is written very poorly?

[amandion]

Thanks for everyone's responses!

However, I don't see how Unicode is involved anywhere in this problem. LabVIEW does not fully support Unicode and depends on multi byte character sets (MBCS) instead.

To be a bit more clear about the application of this problem, the flattened strings are used to pass data from VI to VI. These flattened strings, when displayed in a normal string indicator, will look like garbled text as they are the binary representation of other data types (clusters, arrays. etc). We have no intention of actually displaying the flattened string to the user, in fact we purposely move these string controls and indicators outside of the bounds of any front panel that will be shown to the user.

The issue is that even though these string controls and indicators are not in the bounds of the Front Panel, LabVIEW will still draw all of the characters of the flattened string in the string controls and indicators. These flattened strings can be anywhere from 20kB to 2MB. On a computer that is localized to English, the performance is fine. On a computer that is localized to anything else, their is a significant performance hit which results in a significant delay in drawing the Front Panel.

Through my testing I've found that this is because LabVIEW has a very hard time drawing a large amount of text, specifically the text represented by bytes outside the printable ASCII range (greater than 0x7F or 0x80), on a computer that is localized to almost anything but English in a string control or indicator.

The quick and dirty fix I've applied in our application is to simply hide the flattened string controls and indicators in VI who show their Front Panels. I was hoping maybe someone from NI had any insight.

I hope I cleared up any confusion.

[billko]

That's an insteresting insight.  What if the sluggishness is due to LabVIEW substituting all the non-printable characters with squares?  What if you displayed as hex or dsplayed control characters?

[ToeCutter]

Any NI employees watching this thread? I think this one needs a CAR raising.

[amandion]

---

@billko wrote:

That's an insteresting insight.  What if the sluggishness is due to LabVIEW substituting all the non-printable characters with squares?  What if you displayed as hex or dsplayed control characters?

---

Hi billko,

You're on the right track. I did some more testing. I modified my Random String Generator as follows:

This now allows me to generate a string of random characters within a specific range. I localized my PC to "Chineese"  and ran this VI continuously and timed when the string indicator updated with a stop watch and compared that to what the VI would calculate as timing.

With the string indicator configure as Normal Display and "Number of Characters" equal to 2 million, here are my results.

• Lower Limit = 0x21 Upper Limit = 0x7E. This represents the range of normal, printable Latin characters. Stop watch = 1.5 seconds per run
• Lower Limit = 0x00 Upper Limit = 0xFF. This represents the entire 256 byte ASCII range. The output will be a mix of Latin characters and Extended ASCII characters which will be localized. Stop watch = 21 seconds per run
• Lower Limit = 0x81 Upper Limit = 0xFF. This represents the range of only the extended ASCII range that will be localized text. Stop watch = 44 seconds per run

When I perform the same set of tests with the string indicator set to Hex Display, I get a timing of about 1 second per run across the board. Additionally, the value of the milliseconds indicator was always in the same range, between 174ms and 178ms, in every test.

This tells me 2 things:

1. The delay is occurring post VI execution.
2. The number of characters outside of the printable range in a string is directly proportional to the delay (on a computer localized to about anything other than English) it takes to update the string indicator if the indicator is set to Normal Display.

Hopefully all of this information is useful to someone at NI.

[natasftw]

---

@amandion wrote:

We have no intention of actually displaying the flattened string to the user, in fact we purposely move these string controls and indicators outside of the bounds of any front panel that will be shown to the user.

The quick and dirty fix I've applied in our application is to simply hide the flattened string controls and indicators in VI who show their Front Panels. I was hoping maybe someone from NI had any insight.

---

I'm still confused about this.  Why would you create the indicator in the first place?  If it is something that is never meant to be seen, I can't think of a reason to build an indicator.  Just wire it directly to where you want it to go.  It's part of a subVI.  What benefit do you see from having multiple VIs open rather than having a single user interface to work with?  Many applications have multiple VIs passing data between each other.  If you actually need to have several UIs, look at using the FGV instead of an indicator. 

So really, I have the two questions:

1) Why would you want your user to have multiple UIs to work with?

2) Why would you make an indicator for something you don't want to be part of the UI?

[Yamaeda]

This is quite interesting! Does the indicator make a difference? Is the times the same with a System, Classic, Silver or ...(LV8-style, 3D or what they're called?)

/Y

[Yamaeda]

I've recreated your VI (couldn't use the snippet) and using western settings (swedish) i have ~240 ms for 2.5m characters, regardless of 0-255 or 32-127 and regardless of indicator type.

/Y

[NetoNI]

Hello, 

I am going to take a closer look to this case and will be informing you about the results. 

Thank you all for your suggestions.

Regards,

Ernesto M.

Applications Engineering

National Instruments

[NetoNI]

Hello amandion, 

I was checking and what is going on is that for east asian languages  there will be a character transformation if you do not change  the User Locale and the System Locale. 

If you are using Windows 7 you can change them following the next steps. 

Switch User Locale:

• Launch Control Panel
• Click on Clock, Language, and Region
• Click on Region and Language
• On the Formats tab, select the language of your choice

Switch System Locale:

• On the Administrative tab click Change system locale...
• In the next window select your desired system locale, e.g. Japanese (Japan)
• Hit OK
• When prompted, have windows restarted

Let me know how it goes after following these steps.

Regards,

Ernesto M.

Applications Engineering

National Instruments

www.ni.com/support