Scott Isaac has posted an article some weeks ago why live.com is slow or "What they learned building live.com":

Parsing XML is Slow

We have also learned that merely parsing the RSS XML can be expensive in the browser. When we parse RSS, we are merely translating it into Javascript structures to be further manipulated. Since our server’s are already normalizing feeds to a standard format, instead of serving the RSS feed directly, we are going to translate the feed directly to JSON (Javascript structures). As a simple benchmark, on my fast developer machine we went from 400ms to parse 150K of RSS to 15ms to “execute” the JSON response.

Ajax.NET is working with JSON formatted data since a very early version. I had two problems when using XML: the performance problem and missing (or very different) support in common web browsers. JSON is working in all web browser that can execute JavaScript code. And, why did Microsoft decide to create a new XML scripting language instead of using JSON format to speed up client-side JavaScript code? My expierience is that Atlas live.com is currently only working on fast internet connections with fast clients (maybe running Windows XP with 512 MB ram and a cpu at about 3 GHz). On slow PCs and modem/ISDN connections it is not possible to run these web sites.

There is one more thing I recognized when playing around with live.com. If you click on the refresh icon to update a container showing RSS news your web browser (I tested with Internet Explorer) will be blocked. I didn't had a look inside, but I think the asynchronous call is missing there. So, live.com is not the best web site showing Atlas related developments. I hope Microsoft will show us real web applications that can be used everywhere, on every device,...

Update: Scott Guthrie tells us in a comment below that the slowness of live.com is not comming from the Atlas framework. RSS feeds xml parsing is one of the slow functions from live.com.

6 Comments

• scottgu said Sunday, May 14, 2006 3:36:00 PM

  Live.com's RSS parsing of XML is not using Atlas -- so concluding that Live.com is slow because of Atlas is not accurate.
  
  It is the Live.com layer above Atlas that Steve Issac is talking about optimizing above -- that part is application specific.

• Andre said Sunday, May 14, 2006 5:28:00 PM

  Scott, do you have any web application that is using Atlas without any other "slow code"? Until today I only found web sites that display todo lists or using the virtual earth control. Would be nice to see Atlas in action!!

• Michael Schwarz said Sunday, May 14, 2006 5:35:00 PM

  Scott, sorry for that, I didn't had such a deep look inside the code of live.com. I changed the text...
  
  Do you have any web site that is using the Atlas framework without other slow JavaScript?
  
  Regards,
  Michael

• Mark said Sunday, May 14, 2006 5:38:00 PM

  Searching for Atlas examples, too!

• scottgu said Sunday, May 14, 2006 8:44:00 PM

  I didn't mean to imply that it was slow only because of RSS parsing -- rather it is primarily slow because of all the things the app is doing (of which RSS parsing is one of them).
  
  Scott Issacs article above does a good job of summarizing some of these app-specific perf issues and how they are addressing them. It is well worth a read.
  
  Hope this helps,
  
  Scott

• Jon Diamond said Wednesday, May 17, 2006 8:30:00 AM

  I had similar problems initially I thought it was the site or too many round trips but after a bit of debugging it just has to be down to the xml parsing.
  
  Almost by accident I found the Windows script 5.6 update dratically improves performance (at least it did on the two machines I tested so far), so if you are having painfully slow parsing I'd say go give it a try.
  
  I'd be interested to hear if your experiances improve as dramatically as mine after you apply this.
  
  jd