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

[amandion]

EDIT: I am intentionally misspelling the word for "the language of China" otherwise the forum will censor me, seriously.

We have a large application based on LabVIEW. In this application, we use flattened strings to pass data between VIs. I recently noticed that some VIs who show their Front Panels when called were taking significantly longer to draw their Front Panels on computers that are localized in Eastern languages (Chineese, Korean, etc.).

I eventually traced it down to the fact that if you try to display a large amount of characters (anything over 2000 characters) in a string on a Front Panel where the text in LabVIEW is localized to English, the Front Panel is launched and drawn instantly. However, if the string becomes localized in an Eastern language, say Chineese, it can take significantly longer to draw the Front Panel (anywhere from 40 seconds to 2 minutes or more depending on the length of the string) and the CPU is being taxed.

I've attached a simple VI (LabVIEW 2014) which demonstrates this behavior. It simply generates a random sequence of characters of a predefined length.

In order to notice the problem, follow these steps:

1. Make sure LabVIEW is closed first.
2. In Windows, go to Control Panel > Region and Language.
3. In the Formats tab, observe which language is currently selected. If it is not set to "English (United States)", then switch to that and click Apply.
4. Launch LabVIEW and run the attached VI. You should notice that the string indicator updates almost instantly.
5. Completely exit LabVIEW.
6. Going back to the Region and Language panel in Windows, change the Format drop-down from "English (United States)" to "Chineese (Simplified, PRC).
7. Launch LabVIEW and run the attached VI. You should notice a significant delay it takes for the string indicator to display the text.

Anybody have any idea why this is happening?

Thanks!

[Thomas_robertson]

I work with this individual and for some reason it's replacing the word Chineese with asterisks

[PiDi]

I don't know answer to this question and think it's a bug..

...but the unnecessary censorship of topic title made me laugh just a bit too much 😄

[altenbach]

Just writing some ***** for testing.

Wow, that's silly!!!!

I will report it to the moderator.

[billko]

Do you think it has something to do with double-byte characters?  (Twice as much data to process.)

[amandion]

Hi Billko,

That is an interesting point so I ran a test.

According to this Microsoft documentation:

Windows Code Pages

Hebrew and Vietnam are single-bye character sets like Latin (used for English) in contrast to the double-byte character sets used for the other Eastern Languages. However, If I change my Date/Time format to either Hebrew or Vietnam, I get the same significant delay as I did with "Chineese". Seems like only English performs instantly.

[billko]

Drat.

😄

[Darin.K]

It takes me a really long time to read and write the language spoken in China, so I can understand it being hard for my computer as well....

[natasftw]

https://decibel.ni.com/content/docs/DOC-10153

Regardless of file size, it's still a conversation about unicode vs ascii.  You're dealing with a bit of conversion in addition to simply posting the text.  I wouldn't be surprised if that added some overhead.

I'm curious.  What is it about your application that requires multiple VIs to display their Front Panel at the same time?

[Yamaeda]

Since Unicode is U16, what happens if you in your example multiply by 65000 and convert to U16, does it perform better? 

/Y