Linked by Thom Holwerda on Wed 6th Mar 2013 19:00 UTC
Microsoft One of the major lacking features in the newest Office: no Metro applications. In fact, the only reason Windows RT has a desktop at all is because the Office team was unable to create Metro applications in time for the release of Windows RT. I often thought this was a classic case of two important divisions within Microsoft not getting along and not being aligned, but now that I have my own Surface RT, I'm starting to realise that there's a far simpler, and thus more likely, explanation: Metro is simply not ready for anything serious - or for anything at all, really.
Permalink for comment 554401
To read all comments associated with this story, please click here.
Comment by Nelson
by Nelson on Wed 6th Mar 2013 22:44 UTC
Member since:

The question of performance on low power ARM devices is a tricky one because they vary. For example, Tegra 3 based SoCs are outperformed by the Snapdragon S4 inside of some Windows RT devices.

However, in my experience as a Windows Store dev, I've found a few things to be important:

- Engineering counts. Know what things cost. Ask yourself basic questions like should you perform long blocking actions on the UI thread? I think thread awareness is the new pointer ownership in terms of how important it is to be in the know about how your app works.

- Having a Windows RT device is important. It made a huge difference having a Surface to test my apps on. I was able to see what was a slow path, and usually was able to easily make a better solution.

x86 is super fast for a bunch of things that ARM is terribly slow at. So if you're only testing on your Core i5 laptop, you're going to be in for a surprise.

- Programming language choice matters. A lot. A lot of apps I've seen that are slow on my Surface have been those stupid HTML5/JS apps and usually were written by people who didn't use JS promises correctly or did other blatantly stupid things.

- People don't quite understand the C# async/await model, and are not aware of the nuances of its implementation. You need to know which thread exceptions get thrown off (they differ for async void, async task, asyncs from lambdas, etc.). This personally was a major headache in my own app. I had a few instances where I assumed exception behavior was uniform -- oops its not.

- People don't have experience writing XAML. A lot of them do, but an equal if not larger amount of developers don't. I can tell. If you look at the XAML behind apps you can quickly see which companies paid respected consulting agencies and which companies put a bunch of interns on the job. XAML takes time to know and understand. This ties in to knowing what things cost. Examples being knowing which containers virtualize, which don't, and their relative layout pass impacts.

There's plenty more examples, but also worth noting is that when speaking specifically about Office, its going to be a little more complex to port it over. Office likely has decades of architectural layering caked into the code base. A nightmare to port. I imagine OneNote was more straightforward, but we'll see.

The port of OneNote is no slouch though, peeking at the app container, they use C++, XAML, and DirectX for the canvas. So it seems that they wrote this app with the larger goal in mind of porting other Office apps to it.

I'm not sure if they'll port the apps piecemeal, but its a foregone conclusion that it will, in my opinion.

Another counter example is that Microsoft ported Visual Studio to a mixture of C++, C#, and WPF. This is an architectural feat of the same magnitude -- so it shows at the least, that an equally complex application can be ported to a less capable (from a perf POV) platform in comparison to WinRT. WPF wasn't as tuned for speed as WinRT is, but MSFT made even that work.

However, it took them a few releases to iterate on the code base and fix things. OneNote MX will likely get a lot better. These things are not one shot ports, but on going development cycles. WinRT requires you to change how you approach a lot of problems fundamentally.

-- I disagree completely with this article. I think one of the reasons that WinRT is so exciting is how scalable it is and the performance oriented mindset with which the framework behaves.

Its unfortunate (and a huge miss) that Microsoft let Surface RT have such performance problems (an auxilliary core is OFF on the Tegra 3 because nVidia had engineering issues with the F/W -- which shows a lot of this is just a code base maturity issue and may improve) but we need to also look at the performance of other Windows RT devices that don't run Tegra 3 (and it is much better) as well as how low power CloverTrail devices perform.

Reply Score: 7