Performance Matters To Customers


*****Updated From Original Posting*****


Swashbuckler (who makes frequent, cogent arguments in the comments on my blog) made a comment on my last posting which I think is a good point of discussion.


My understanding is that the performance issue traces back to a design goal of ODF that was laudable. The idea was to create the XML with developer purity in mind and thus the XML used is verbose. Microsoft spent many millions (more than a few) on tuning the binary formats we used over the years. Thus, a core design goal for our XML formats from the beginning (5 years ago) was that they had to perform as well as possible given the inherent factors of using XML vs. binary formats. Thus, we use a highly optimized XML syntax.  Our customers who are working with large files on a regular basis are willing to make a minor trade-off for the flexibility of XML, but not a major one (difference of 4 or 5 seconds in opening/saving ok - not 18-20). They want to have their cake and eat it to - as they should.


Complex docs, spreadsheets, slide decks etc. are used all over the world and in business-critical situations. Banks work use/produce tens of thousands of highly complex spreadsheets on a daily basis. Look at the healthcare industy, the legal system - they all depend on complex documents where things like performance play a very real role in their choice of solutions.


We cannot lose site of what our cusotmers' needs are. If MS were to release Office 2007 with a 10x decrease in performance of the opening/saving of docs we would face many very angry customers. 


It made many of the ODF advocate community upset when I made this statement in the press, but I will make it again and apologize again for the consternation it may cause. The standards food fight under way about formats is a great way to redirect the conversation away from the realities of the commercial offerings. I firmly believe that this ultimately is an issue of competitive products and the value that they offer their customers.


 


[The update of this posting is due to a misunderstanding on my part of information shared with me from the Office Team. I was under the impression of performance parity between the binary formats and the XML - I was mistaken and apologize. I try hard to keep the information in this blog as factually accurate as possible. As always, feel free to call me on my mistakes.]

Comments (2)
  1. orcmid says:

    I find your analysis on this point to be extremely rational and realistic.  I think the legacy is a big deal, and getting out of the way of the customers getting their work done (a performance-related matter) goes with it.

    And then I get a little nervous about the challenge of meeting the conformance bar set for specifications like OOX at its current draft level in ECMA TC45.  I love the tightness of the conformance definitions and the way implementation-defined elements are constrained.  And I’m nervous.

    It will be great to have all of the bits be stable, the specs be published, and we can deal with profiling, interchange arrangements (by different communities as needed), and the practical aspects of all of that.  I’m looking forward to practical matters of fact, shared interests and concerns, and less simplistic ideological posturing (from everyone).  

    I completely agree that customers are the deciding force and not dilettantes such as myself.

  2. MSDN Archive says:

    Jason, you’re dead on. Coming from one of the Microsoft teams working to make the SaaS vision a reality — and from a team that works directly with enterprise customers, performance is everything. I recently blogged on the topic of network acceleration at http://www.plmblog.com/2006/09/when_saas_was_a.html, which looks at one way we’re trying to solve this problem in a hosted environment.

    Customers are definitiely willing to make some concessions to workflow and platform flexibility as long as 1) you can simplify their problems, 2) the cost is close to (+/-) what they’d pay on their own, and 3) performance is there.

Comments are closed.

Skip to main content