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.
Thread beginning with 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
Nelson
Member since:
2005-11-29

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

RE: Comment by Nelson
by chithanh on Thu 7th Mar 2013 00:59 in reply to "Comment by Nelson"
chithanh Member since:
2006-06-18

One company which ought to know how to engineer well-performing stable Metro apps is Microsoft themselves. But according to the article, Microsoft's own apps are affected by performance and stability problems too.

Let's hope that with increasing developer experience and in the absence of major goofs like the infamous "Silverlight network I/O in the UI thread" the issues with the existing apps can all be addressed.

Regarding Office, Microsoft is currently working on Office for Android and iOS. If they have wisely chosen a proper cross-plattform development framework, then a WinRT port can come almost for free out of that.

Reply Parent Score: 6

RE[2]: Comment by Nelson
by Nelson on Thu 7th Mar 2013 01:09 in reply to "RE: Comment by Nelson"
Nelson Member since:
2005-11-29

One company which ought to know how to engineer well-performing stable Metro apps is Microsoft themselves. But according to the article, Microsoft's own apps are affected by performance and stability problems too.


It is inevitable that apps will have bugs and performance issues in their initial releases. I don't care who you are, what background you come from, or what you've done in the past.

Even when porting large legacy software, in fact, especially when porting large legacy software.

OneNote MX works well for me on the Surface, yes there are small (small perf problems) but they're not major. Usually if I paste a large swathe of content with diverse styling, a bunch of tables, etc.. I get a slight delay in pasting (Never becomes unresponsive, just a quick progress indicator).

The quality of apps varies from team to team. For example the Bing apps are generally excellent in my opinion. Xbox Music blows. OneNote is good. SkyDrive is good.

Its going to vary with the maturity of the product, how service oriented the team is, etc.

Bing can do a great job because they are used to porting to mobile and other platforms. Its a simple consumption based app.

SkyDrive, the same deal. OneNote has been ported to Windows Phone so it could take cues from there.

However for a larger program like Mail (they actually implement an ActiveSync client in javascript, Mail is an HTML5 app) it'll take longer for improvements to come. I do hope they come soon. I hate Mail.

The good thing about Windows 8 is that the only app which is tied to the system is the Store. You can replace every stock app with a (theoretically) better one.

Uninstall mail, write an app to handle the mail protocols and URIs, and you have your replacement. Its a breath of fresh air. Let the market sort this out, if Microsoft doesn't make apps you like, then someone else should. Its a compelling enough proposition.


Let's hope that with increasing developer experience and in the absence of major goofs like the infamous "Silverlight network I/O in the UI thread" the issues with the existing apps can all be addressed.


Ugh. Don't get me started on that bone headed decision. It wasn't really network I/O on the UI thread, it was (only on Windows Phone) the continuation from the asyncrhonous operation firing on the UI thread.

So while the network request took place in the background, if you parsed the JSON or RSS or whatever, unless you knew better, this happened on the UI thread.

Amazingly, it got worse. It was also the case that images were decoded on the UI thread. Don't worry, no such nonsense exists on WinRT.

Async/Await takes the ambient SynchronizationContext which means it returns on the thread its started on. If its fired from a UI thread it returns on one, if not, it doesn't.


Regarding Office, Microsoft is currently working on Office for Android and iOS. If they have wisely chosen a proper cross-plattform development framework, then a WinRT port can come almost for free out of that.


Good point. I hope this is their strategy going forward.

Reply Parent Score: 4

Native Office for WinRT
by modicr on Thu 7th Mar 2013 23:26 in reply to "RE: Comment by Nelson"
modicr Member since:
2005-09-20

One company which ought to know how to engineer well-performing stable Metro apps is Microsoft themselves. But according to the article, Microsoft's own apps are affected by performance and stability problems too.


History repeats itself!
Windows 1.0 was released on 1985-NOV. But there was no Word for Windows. In the meantime Windows 2.0 was released (1987-DEC).

"Windows 2.0 allowed application windows to overlap each other unlike its predecessor Windows 1.0, which could display only tiled windows." (wikipedia)

Word for Windows was released two years later (1989-NOV)!

See:
1) http://diegobasch.com/do-you-know-how-long-it-took-to-develop-ms-wi
2) http://www.brilliantsheep.com/analysis-of-microsofts-project-opus-c...

So if we now adapt history to WinRT:
WinRT 1.0 was released on 2012-OCT.
WinRT 2.0 will be released on 2014-NOV (with Windows 9.0 / WinNT 7.0).
Fully functional native Word RT 1.0 will be released on 2016-OCT. ;)

Cheers, Roman

Edited 2013-03-07 23:27 UTC

Reply Parent Score: 4