MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

writing a component won’t necessarily give you a good return on the time you invest; it will be more
productive to just stay in JavaScript. But using a component in a few places where performance really
matters might pay off handsomely.
Tip There is much more to measuring and improving app performance than just offloading
computationally intensive routines to a WinRT component. The Analyzing the performance of Windows
Store apps and Analyzing the code quality of Windows Store apps with Visual Studio code analysis
topics in the documentation will help you make a more thorough assessment of your app.
I also want to add that when I first ran these tests with the example program, I was seeing something
like 100% improvements in C#/C++ over JavaScript. The reason for that had more to do with the nature
of the canvas element’s ImageData object (as returned by the canvas’s createImageData method) than
with JavaScript. In my original JavaScript code (since corrected in Chapter 10 as well), I was
dereferencing the ImageData.data array to set every r, g, b, and a value for each pixel. When I learned
how dreadfully slow that dereference operation actually is, I changed the code to cache the array
reference in another variable and suddenly the JavaScript version became amazingly faster. Indeed,
minimizing identifier references is generally a good practice for better performance in JavaScript. For
more on this and other performance aspects, check out High Performance JavaScript, by Nicholas C.
Zakas (O’Reilly, 2010).
Sidebar: Managed vs. Native
As shown in the previous section, going from JavaScript to C# buys you one level of performance
gain, and going from C# to C++ buys another. Given that C++ is often more complex to work
with, it’s good to ask whether the extra effort will be worth it. In very critical situations where that
extra 13–22% really matters, the answer is clearly yes. But there is another factor to consider: the
difference between the managed environment of .NET languages (along with JavaScript, for that
matter) and the native environment of C++.
Put simply, the reason why C#/VB code is often easier to write than C++ is that the .NET
Common Language Runtime (CLR) provides a host of services like garbage collection so that you
don’t have to worry about every little memory allocation. What this means, however, is that your
activities in C#/VB can also trigger extra processing within that runtime that could change the
performance characteristics of your components.
For example, in the Image Manipulation example with this chapter—which really expanded
into a test app for components!—I added a simple counting function in JavaScript, C#, and C++
(they all look about the same):
function countFromZero(max, increment) {
var sum = 0;
for (var x = 0; x < max; x += increment) {
sum += x;
}
730