Performance traps for C++/CX

Writing an application using C++/CX is not the same as writing a normal C + + application. The interoperability between pure C + + code and Windows Runtime (WinRT) is surprisingly expensive. Based on Sridhar Madhugiri video c++/cx Best practice content, we've listed some ways to avoid performance problems in Windows 8 development.

Boundary

There are a variety of performance hurdles on the boundaries of your application.

Data conversion is one example of this. Consider a typical boundary between a Web service client and the rest of the application. Most Web services are encoded using UTF-8, while the interior of most Windows applications is encoded using UTF-16. UTF-16 encoding is so popular in windows that people sometimes mistakenly refer to it as "Unicode" encoding. The cost of a data conversion may be fixed, or it may vary widely, depending on its specific value in the data itself.

The next performance consumption comes from type conversions. For example, you may need a wstring, but there is a wchar_t *. Although the data that each type contains in memory looks the same, copying the content from one data structure to another is still a performance cost.

The last kind of performance consumption comes from data replication operations. Sometimes you have to pay for data replication at the border, even if they don't require data conversion or type conversion.

Why do we have to discuss these things now? The reason is that WINRT itself is the boundary between the application and the rest of the operating system. The essence of writing high-performance C++/CX applications is to identify boundaries and, where possible, avoid crossing boundaries.

If operations across WINRT boundaries are unavoidable, look for ways to reduce the number of data replication, type conversions, and data conversion operations. For example, if both the data source and the target use UTF-8 encoding, then there is no need to convert the data to UTF-16 because you will eventually need to convert it back.

String

In most applications, strings are the primary data type. The areas of file systems, Web services, UIs, messages, runes, and contracts are increasingly dependent on strings. Unfortunately, there are very many types of strings used.

Internally, most applications may use std::wstring or std::wchar_t*, as do most third-party libraries that you rely on. But you need to switch to platform::string^ when communicating with the WINRT class library. Each conversion requires a memory allocation and a data copy operation.

A key difference between string^ and the local C + + version is that string^ is immutable. The WINRT runtime's emphasis on immutable strings may come from. NET and the CLR. As the ^ symbol indicates, string^ is also a reference count.

People may argue about the merits of variable and immutable strings all day long, but there is only one truth in the end. Because the C + + standard class library understands only variable strings, and WINRT only understands immutable strings, you must deal with both. As mentioned earlier, this means that you need to copy the string.

Class Library Author: If you are building a general-purpose class library for others to use, you should consider providing a number of different versions of the API to provide an API for each type of string. This way you don't have to guess which string type the user of the API is using when invoking the class library.

Many string based operations do not actually need to use strings, but developers prefer to use string iterators. Because the iterative operations of variable and immutable data structures are the same, you can use regular Xxx_iterator (string), End (String), ...) The syntax of the string platform directly creates STL-style iterators.

In addition, you should first look for APIs that return wchar_t* directly, rather than encapsulating it as a wstring. If you find such an API, you can create a new platform string by the address of the first element in the array and the length of the array. This does not require creating a wstring that will be discarded immediately after a matching platform string is created.

There is a little trick when calling the WinRT API with a string reference (stringreference) type input parameter. You can pass a wchar_t* or wstring parameter to a WINRT function with a parameter type of platform string, in which case a lightweight look is created. Anyway, here are some places to watch out for.

The string must be NULL to terminate or an error will be thrown.

If a string changes anywhere outside the function, the result cannot be determined.

If there is a reference to any string within the function, a full copy will be generated anyway.

Article 1th above is easy to verify, and 2nd will only happen when you encounter thread-safety issues. This should be a very useful technique in most environments.

Class Library Author: To make sure that the above scenario is true, first try to avoid having it refer to the string you obtained in the stringreference parameter. Because subsequent references do not introduce additional replication, do not worry about using a second reference.