I wrote about creating WinRT components in C#/VB in Chapter 16 of my book, and you can use such components from JavaScript. However, we’re seeing significant issues with the memory footprint of apps when you have both the JavaScript and the .NET runtime (CLR) loaded in the same process, so we’re recommending developers avoid that situation. Here’s a writeup from my teammate Kyle Marsh:

As Windows 8 has been gaining adoption Microsoft has been gathering more data from participants in our various feedback programs. One thing we observed in this data is pattern of memory usage spikes from Windows Store apps using JavaScript when the apps also use components built with C# or VB.

We know from the data we gather from Windows telemetry that users running multiple apps on less powerful hardware will occasionally encounter situations where the hardware cannot handle all the tasks. When this happens, system performance can degrade rapidly and  a spike in memory usage for apps that mix JavaScript and C# or VB is unavoidable.  Users who have more powerful hardware, or who run very few apps simultaneously, are less likely to be impacted but may still encounter reduced performance in certain situations.

Being conscious of the memory being used in the app can avoid exacerbating the problem, but it will not eliminate it.  Even well written apps will face a significant increase in memory footprint when mixing both JavaScript and C# or VB. We therefore recommend that developers avoid these memory spikes by not mixing JavaScript and C# or VB in their apps.

For developers who to provide components that can be used by JavaScript apps we recommended that you implement components with C++ instead of C# or VB.  C++ apps are compiled ahead of time and run directly on the OS, or in hardware, which every process already loads so there is no additional memory penalty for native code. Providing components in native code also avoids having two execution environments, thus it dramatically reduces the memory footprint and the likelihood of memory usage spikes.


2 Comments

  1. Chris
    Posted March 6, 2013 at 3:15 pm | Permalink

    Why in the world hasn’t this been detected before?
    Also, it is VERY disappointing to see that Microsoft actually promotes native code over the managed alternative. Is the march toward a fully managed world (including the OS) is vanishing?

    • Posted March 6, 2013 at 5:03 pm | Permalink

      Chris, I think you're missing the point that this is specifically about the best way to write WinRT components that will be used by an app written in JavaScript. The post describes the specific facets of the concern, and how we've been noticing patterns from telemetry on low-power devices. It says nothing about writing apps in .NET languages, which is and will be entirely supported. Plus you can use WinRT components written in .NET languages from apps written in those languages (and C++) without any problems. So be careful not to read more into this than needs be.

      Understand too, that this issue is primarily one of memory consumption and having two managed code engines (JS and the CLR) in the same process. If you're on an 8GB+ machine, it's not a big deal. It's becomes more of an issue with ARM devices and such where memory consumption (and resulting performance) becomes a real concern.

      Again, the recommendation here is primarily targeted toward those writing reusable libraries as WinRT components: best to do it in C++. Perhaps we can find ways to reduce the CLR overhead in the future. This is not at all about "promoting" one path over another where app development is concerned.