Slashdot Mirror


Microsoft Claims OpenDocument is Too Slow

SirClicksalot writes "Microsoft claims that the OpenDocument Format (ODF) is too slow for easy use. They cite a study carried out by ZDNet.com that compared OpenOffice.org 2.0 with the XML formats in Microsoft Office 2003. This comes after the international standards body ISO approved ODF earlier this month." From the ZDNet article: "'The use of OpenDocument documents is slower to the point of not really being satisfactory,' Alan Yates, the general manager of Microsoft's information worker strategy, told ZDNet UK on Wednesday. 'The Open XML format is designed for performance. XML is fundamentally slower than binary formats so we have made sure that customers won't notice a big difference in performance.'"

12 of 553 comments (clear)

  1. INCITS by eldavojohn · · Score: 5, Insightful

    What I didn't see mentioned in this article was the fact that back in March, Microsoft joined a subdivision of INCITS (V1 Text Processing: Office and Publishing Systems Interface group within the International Committee for Information Technology Standards). Which is the group that kind of decides whether or not it should be widely adopted. Being ISO certified is one thing but it doesn't mean everyone's going to use it as a standard.

    There was much speculation that Microsoft had joined INCITS with the intent to slowdown or stop the spreading use of ODF and insert their own standard. Sounded like another Microsoft power trip to me.

    I predict that Microsoft will bitch and bitch about ODF and then release study after study suggesting some other patent laden format (probably Open XML) over ODF. This is just the first complaint against ODF--too slow. Perhaps next they'll complain that it's not documented well enough, some of their apps just can't support it, it gives their developers arthritis, it looks too ugly, etc.

    --
    My work here is dung.
  2. If I was an MS shill. by Whiney+Mac+Fanboy · · Score: 5, Insightful

    If I was an MS shill (like so many in these forums seems to be), I would be deeply, deeply ashamed that the company I pimped myself out for was incapable of distinguishing between a document format and an application.

    (read the 'study')

    But I am sure the shills will pipe up with "easier to use", "people are used to it", "noone forces people to use MS" and other such irrelevance.

    --
    There are shills on slashdot. Apparently, I'm one of them.
    1. Re:If I was an MS shill. by Bob9113 · · Score: 5, Insightful

      Although it is complete true that the distinction between application and document format is key, it is quite possible to design a document format with performance in mind versus merely counting on Moore's law to handle performance issues. My observation is that Microsoft has thought through some performance and reliability details to an impressive degree in OpenXML.

      Performance optimization should be extremely limited before the product is feature complete and in the hands of at least expert customers, and preferably the real customers. Performance optimization is in tension with programmer friendliness. ODF is zipped ASCII XML with binary embeds (eg: raster graphics) stored in a separate part of the zip - it is really easy to generate documents (I have written a few apps that do it). MS XML is not going to be so easy - inline binary and lookup tables for content. Do you want nicely encapsulated code that can meet the customer's evolving needs without developing bugs (eg: Office's security holes), or do you want a document format that can run on a Pentium 60?

      I work for a very large company that has had a number of teams developing code on several different ideologies for the five years that I have been here. I have been able to see up close the long term cost/benefit of teams that write heavily optimized code versus those that write code that is heavy on OO theory at the expense of performance (and versus those that write code that is neither clean nor fast, which is kind of funny/painful to watch). In the long run, there is no competition - the maintainable code wins hands down for anything that has evolving customer needs (which, except for those that have been cancelled, is every project I have seen).

      The zip file is stream decompressed so that a lost bit halfway through the file does not prevent decompression of the beginning. Textual data is earlier in the file than bitmap data both because it is needed sooner and also because a truncated file will still have its text and basic formatting intact.

      That is the very epitome of inappropriate technical magic put in place by the, "Shouldn't our code handle hypothetical situation X?" people. It makes the code harder to write, understand, and maintain, and it solves a problem that doesn't happen in normal operating conditions. If there's a problem with software or hardware failures during write, do what OOo and MSO already do - keep a backup while the file is open. Once the file is on disk, it is very unlikely to be truncated or bit-flipped unless the drive goes bad (in which case you are going to have a hard time recovering it anyway). If you need your data to withstand drive failures, use an off-disk, off-site, or off-line repository as appropriate.

  3. It's a fucking WORD PROCESSOR by Anonymous Coward · · Score: 5, Insightful

    It's not a game loading complex 3D worlds and sound effects, it's a load of text being displayed on screen. What difference does a few milliseconds here or there make? OpenDocument could be ten times slower and the benefits of an open document format would still vastly outweigh the effects of loading time.

  4. Re:I don't know about the rest of you... by Eideewt · · Score: 5, Insightful

    It's pretty important to me. The thing is, I highly doubt that ODF is naturally slower than MS's format. They're both XML, right? How can one take that much longer to parse?

    In fact, the study cited doesn't even refer to "the speed of ODF". It's about OO.o's speed only.

  5. Re:I don't know about the rest of you... by peragrin · · Score: 5, Insightful

    No MSFT's formt is a Binary XML, with binary data encased by XML tags. Images are stored directly in the file unlike ODF which is a zipfile, with a subdirectory for images.

    In other words if you don't have an ODF appilication all you have to do is unzip it( a feature found in most OS's these days) and extract the data by hand.

    If you don't have MSFT Word of version x you can never open MSFT's formats. Patents will prevent third parties from implenting it. Defeating the entire point of having a standard.

    --
    i thought once I was found, but it was only a dream.
  6. Uhmm... by Egonis · · Score: 5, Insightful

    You mean to tell me that parsing a file at an average of 200k of data is too slow on 1.0+GHz processors?

    OPTIMIZE YOUR CODE!

    I know that there are many variables here, but seriously... how slow can it be? I use OpenOffice 2.0 on an Athlon64 3200+ and I have no issues, in fact, I find it much quicker than M$ Office

  7. Re:I don't know about the rest of you... by Shisha · · Score: 5, Insightful

    This is typical FUD! The article is not comparing the speed of OpenDoc vs Microsoft's Open XML. It's comparing the speed of OpenOffice vs. Microsoft Office. It does not make any sense.

    How about if someone with a Windows PC at hand compared the speed of opening and saving OpenDocument vs. the usual .doc to give us some real numbers. (Microsoft's Open XML is not even available to compare speeds!)

    I'm sure Microsoft would very much like to shift the debate from OpenDocument vs. Open XML to OpenOffice vs MS Office. Let's not fool ourselves MS Office has many advantages.

  8. Oh Right... by Greyfox · · Score: 5, Insightful
    Like performance has ever been a cocnern of Microsoft's. If that were the case, window frames would be handled outside the application so that you could still operate on the window if the application freezes up. If that were the case, Outlook would gather mail in a separate thread so that when the exchange server stops responding I'd still be able to read and compose local email. Or minimize its fucking window. If that were the case, no application could sieze control of eveything else going on at the moment to tell me it's done searching and that I should now click OK.

    In fact, until this very day I didn't even realize that performance was even in Microsoft's dictionary, and like so many other words Microsoft uses I don't think it means entirely what they think it means. Newsflash, Microsoft, "innovation" does not mean "steal other people's ideas." "Security" does not mean "It'll be taken over before you can download the first update for it." And "performance" doesn't mean "the entire fucking system stops for 30 seconds when some application decides to stop handling its windows controls." Now STFU and go back to pushing your poison kool-aid on unsuspecting consumers before Apple eats your lunch.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  9. Re:I don't know about the rest of you... by suv4x4 · · Score: 5, Insightful

    It's actually likely they're slightly faster for spreadsheets. For example:

        * they use single-letter tag names, for the most part, to reduce parsing time
        * they remove all strings and put them in a look-up table


    Thing is XML was desgiend to be readable and easy to parse. If you start doing hacks like embedding tons of binary data (OpenXML has images embeded in the XML), using one letter tags and look-up tables, you've essentially a bloated binary format.

    You can call it an XML, it's technically XML, but it really isn't.

    It would be better that Microsoft offers an open binary format, but truly open, patent free. XML is really heavy compared to efficient binary formats. Compressing the resulting XML makes XML formats on par with binary as to size, but that's just faking it: the program will have to decompress it and parse an XML, which is tons harder that directly parsing binary offsets and bits (for a machine).

  10. Well... is it $200 slower? by popo · · Score: 5, Insightful


    Because "free" still means more to me than an additional 1.7 seconds.

    --
    ------ The best brain training is now totally free : )
  11. Re:I don't know about the rest of you... by jinxidoru · · Score: 5, Insightful

    The parent had a lot of good things to say except this comment: The idea that XML-based documents are "inherently" slow is silly.

    No, the idea that XML-based documents AREN'T "inherently" slow is silly. Of course an XML-based document will be slower than a binary document. XML gives a number of niceties, in the form of maintainability and platform-independence, but it can never be made faster than a well designed binary document. That's just the trade-off.