10-03-2014 04:41 AM
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?
10-03-2014 08:31 AM
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.
10-03-2014 09:11 AM
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?
10-03-2014 09:35 AM
Any NI employees watching this thread? I think this one needs a CAR raising.
10-03-2014 10:29 AM
@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.
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:
Hopefully all of this information is useful to someone at NI.
10-04-2014 07:50 PM
@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?
10-06-2014 03:17 AM
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
10-06-2014 03:30 AM
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
10-06-2014 02:13 PM
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
10-06-2014 04:14 PM
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:
Switch System Locale:
Let me know how it goes after following these steps.
Regards,
Ernesto M.
Applications Engineering
National Instruments