10-02-2014 02:58 PM - edited 10-02-2014 03:20 PM
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:
Anybody have any idea why this is happening?
Thanks!
10-02-2014 03:01 PM
I work with this individual and for some reason it's replacing the word Chineese with asterisks
10-02-2014 03:08 PM
10-02-2014 03:29 PM - edited 10-02-2014 03:30 PM
Just writing some ***** for testing.
Wow, that's silly!!!!
I will report it to the moderator.
10-02-2014 03:57 PM
Do you think it has something to do with double-byte characters? (Twice as much data to process.)
10-02-2014 05:18 PM
Hi Billko,
That is an interesting point so I ran a test.
According to this Microsoft documentation:
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.
10-02-2014 07:26 PM
Drat.
😄
10-02-2014 07:29 PM
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....
10-02-2014 07:58 PM
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?
10-03-2014 02:40 AM
Since Unicode is U16, what happens if you in your example multiply by 65000 and convert to U16, does it perform better?
/Y