Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Microsoft Claims OpenDocument is Too Slow 553

Posted by Zonk
from the compared-to-the-blazing-speed-of-.doc dept.
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.'"
This discussion has been archived. No new comments can be posted.

Microsoft Claims OpenDocument is Too Slow

Comments Filter:
  • by BHearsum (325814) on Friday May 26, 2006 @08:10AM (#15409001) Homepage
    But how fast a document opens is one of my last concerns here.
    • by Monoman (8745) on Friday May 26, 2006 @08:16AM (#15409044) Homepage
      It does when you are writing MS Office worms and viruses. :-)

    • by giorgiofr (887762) on Friday May 26, 2006 @08:19AM (#15409060)
      De vulpe et uva.
    • I for one care not, especially since the study has been done by none other than the ever so neutral ZDNet. I mean, they're not Microsoft biased one little bit.

      *cough*

      • by Shisha (145964) on Friday May 26, 2006 @08:43AM (#15409245) Homepage
        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.
        • It's comparing the speed of OpenOffice vs. Microsoft Office. It does not make any sense.
          MS promoting the new Chewbacca Document Format and is using the proper defense to shore up their claims of it's superiority :)

          (yes, every tag in the CDF is "aaaaawrwwwggggg" - and you thought it was binary data - It's Wookie dammit!)

        • by Anonymous Coward on Friday May 26, 2006 @09:23AM (#15409531)
          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.

          Not very scientific, but I tried to do this test. I opened a big Word doc I have (80 pages), and re-saved it in ODT using OpenOffice 2.0. Then I opened both docs a bunch of times (did them in different orders, sometimes with OpenOffice already open, sometimes not).

          End result: OpenOffice 2.0 opens ODT about twice as fast as it opens Word .DOC files (it took about 1 second to open the doc and about 0.5 seconds to open the ODT).

          It is not surprising that OpenOffice opens its preferred (well-documented) format faster than it opens someone else's non-documented format.

          The inverse test (opening both DOC and ODT in Word) is not possible for obvious reasons! However opening the .DOC in Word was even faster (0.3 seconds? ... hard to measure).

          Conclusion: Word opening DOC is probably faster than OO2.0 opening ODT. However the difference is so small that no one should care (on modern hardware especially). Furthermore there's no reason not to believe that opening of ODT documents will get faster and smoother as time goes on, since the standard is published and algorithms for opening ODT can be improved openly with time. Not only that, but since OO2.0 is open-source, it's particular implementation can be improved.

          On the flip side, just yesterday I tried using MS PowerPoint on a macintosh to open a big presentation (lots of graphs). Opening (and manipulating) the file was unbearable (took minutes to open on the Mac, even though MS PowerPoint on Windows opens it in a few seconds). Strangely Keynote opens it in a few seconds. So Microsoft even has trouble efficiently opening their own binary format! The idea that XML-based documents are "inherently" slow is silly. It has everything to do with the algorithm (which is good for MS Word, bad for MS PowerPoint for Mac, and decent for OpenOffice).

          • Watching microsoft's other apps (for example: publisher) open or save word files can be quite amusing, publisher's support for word files is attrocious, far worse than openoffice infact...

            It's quite disturbing how microsoft can't open their own format correctly, even with access to whatever documentation exists and full source code of an existing implementation.
          • by jinxidoru (743428) on Friday May 26, 2006 @11:45AM (#15410581) Homepage
            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.
          • The problem on the Mac (esp. if it is one of the newer Intel-based macs) is that Office is probably running under Rosetta translation, which probably entails a heavy performance hit, esp. if it involves graphics, etc. (tasks that would have typically used Altivec). I saw a colleague give a presentation with PowerPoint on a MacBook Pro, and it invariably struggled when any kind of graphic came up. Hopefully, MS will have Universal Binaries soon, and Keynote probably already is, even though I don't remember
          • by symbolic (11752)

            I seem to remember a rather depressing benchmark with respect to how fast OOo was able to save and re-open a large spreadsheet- and how much memory was required to do so. The results were not pretty, and would have definitely qualified as something that goes into the "must improve asap" category. I use primarily open source apps, but I have to admit that this performance benchmark was a little disappointing. Here's a to a related ZDNet article: http://blogs.zdnet.com/Ou/?p=119 [zdnet.com]
        • I would help fix the speed and memory usage of OpenOffice but the JCA Sun makes you sign to submit code prevents me from contributing.
    • by Eideewt (603267) on Friday May 26, 2006 @08:22AM (#15409085)
      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.
      • by albalbo (33890) on Friday May 26, 2006 @08:27AM (#15409124) Homepage
        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

        I'm not sure how much difference these things actually make in practice, but there's probably a little speed there.

        What's not fair is to compare OOo to Microsoft Office, and determine the speed of OpenDocument versus OXML based on that...
        • by suv4x4 (956391) on Friday May 26, 2006 @09:06AM (#15409407)
          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).
          • by KonoWatakushi (910213) on Friday May 26, 2006 @10:27AM (#15409984)
            Thing is XML was desgiend to be readable and easy to parse.

            XML is a miserable failure on both counts. It may technically be readable, but it is excruciating. Easy to parse, it most certainly is not. About the only thing it has going for it, is that it is an extensible standard.

          • 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.

            ...and it can also be written with any program that can read and write text. Right now, today, I can generate valid OpenDocument files with standard Unix command line tools and simple "print" commands in common scripting languages. While that isn't valuable to the average user, it's extremely handy for those of us who want to generate documents dynamically with as little overhead as possible (example: sending quotes based on form input on a website).

            Beyond that, XML is human readable (even if not terribly convenient). I can read well-designed XML documents with any text editor. 100 years from now, I'll still be able to glean the content of OpenDocument files with any program that understands by-then legacy encodings like ASCII. If a binary spec is lost, though, so are the documents written with it.

      • by peragrin (659227) on Friday May 26, 2006 @08:32AM (#15409162)
        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.
        • Alright, that's pretty much the Maximum-FUD version of the story, stretching the truth pretty far. Hopefully someone articulate will set the story straight and the moderators won't have to reward the loonies.

          Bottom line is that ODF is a better format -- it's a cleaner format and superior for archival purposes.
        • This point hits the nail right on the head.

          The idea with XML is to have a portable format that can be used by various applications/services (web, editors, and XML backend parsers).

          The power with XML is that not only does it describe a document - but that it can also be parsed by search engines and meta data can be embedded which all taken together - allow your documentation to also serve as a data source for various applications - (tied to RSS feed perhaps, part of taxonomy based search engine etc..) some o
      • Both XML, for certian values of XML.

        Last I looked MS's "XML" was full of big undocumented binary blobs it liberally shat, I mean salted, the file with. As MS's file formats are often pretty literal representations of their application's internal state it's likely doing a half-structured-XML/half-DOC-blob save is indeed faster then doing a full conversion to more interoperable XML.

        Or mebbe they've cleaned up their XML so it's now the beatifully structured text marvel many expected when MS said they were

      • They're both XML, right? How can one take that much longer to parse?

        Well, for one thing, if one stored the formatting and type face information on an as-needed basis, while the other stored it on a per-character basis, which would you expect to be quicker to parse?

        (Yes, it's a facetious example, but you get the idea)
    • To thoses that work with ms-0ffice documents a good portion of the day then the time to open a document is a major problem.
      However read time is not the major problem, it is how long it takes to save the document. Don't forget you have automatic saves every 10-15 mins and when that takes more then just a second or two it is a really major pain and interruption to the job.
      • so someday soon the saving gets done by a process that runs on another core of your multi-cored wonder processor than the one you're using to edit
      • Don't forget you have automatic saves every 10-15 mins and when that takes more then just a second or two it is a really major pain and interruption to the job.
        What do you mean? Do your automatic saves freeze your word processor or something?! That in itself is bad behaviour (bug, even?). You should of course be able to go on with your editing while saving. Then you will perhaps not notice even if it takes a minute.
      • Don't forget you have automatic saves every 10-15 mins and when that takes more then just a second or two it is a really major pain and interruption to the job.

        Dude, I hate to break it to you, but this is 2006. We've had multi-threaded applications for how many years now? Spin off another thread for the auto-save process. Word already does this.
      • For the majority that probably means using Word at work, which further means documents are probably on a server. By far the biggest headache is the way Windows locks the app, and often every other network aware software running concurrently, until the network transaction in focus is complete. Exchange does it, as does IE. These user lock-out so far exceed the delay opening an OpenOffice document it takes cajones the size of moons for Microsoft to point fingers at ODT. Come back when you've fixed those issue
    • i don't know. This morning I opened a 1 page word document (with a single macro that inserts a date) that was created about 6 months ago and for some unknown reason it took around 1 minute to load all the other applicationed stopped responding and strangest of all on my T41 laptop the trackpad stopped responding while the little stick mouse worked fine?
  • INCITS (Score:5, Insightful)

    by eldavojohn (898314) * <eldavojohn.gmail@com> on Friday May 26, 2006 @08:10AM (#15409002) Journal
    What I didn't see mentioned in this article was the fact that back in March, Microsoft joined a subdivision of INCITS [infoworld.com] (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.
    • Re:INCITS (Score:3, Funny)

      by GPLDAN (732269)
      They'll release a study that shows that ODF causes cancer in lab mice.
    • Re:INCITS (Score:3, Interesting)

      by Manitcor (218753)
      where have you been? Almost every single one of those arguments and more were used by MS when the state of MA decided to standardize on ODF.
    • by jdbartlett (941012) on Friday May 26, 2006 @09:37AM (#15409611)
      • ODF also stands for Oregon Department of Forestry, we're worried our Oregon customers will become confused.
      • ODF also stands for Orientation Distribution Function, we're worried our crystallographer customers will become confused.
      • ODF doesn't have a Start button.
      • ODF encourages piracy. You know, document piracy.
      • ODF undermines our current business strategy and is unfair to Microsoft.
      • Microsoft supports Open formats such as ODF...
      • ...in fact, we've introduced some exclusive new features to make ODF even better! (only available in Microsoft Office 2008, make that 9, no, 2010, maybe...)
      • Profit.
  • by Whiney Mac Fanboy (963289) * <whineymacfanboy@gmail.com> on Friday May 26, 2006 @08:11AM (#15409003) Homepage Journal
    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.
    • Article is pure FUD. They run a series of articles attacking OOo OOo is much slower than Office at the moment. It has nothing to do with ODF versus Open XML. In any case the comparisons with Office's current implementation of XML and ODF (under OOo) were much closer.

      When I used OOo I didn't think it was fast but it was nowhere near as slow or as much of a memory hog as this test found.

    • by smallpaul (65919) <[ten.docserp] [ta] [luap]> on Friday May 26, 2006 @08:26AM (#15409114)

      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. The files are sorted in the zip file in the order that they are needed for incremental loading. 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.

      Obviously this Microsoft dude is not making any kind of fine distinctions. But I would love to see a careful analysis of the performance and reliability choices made in OpenDocument versus OpenXML if only so that OpenDocument can copy the best (unpatented) ideas from OpenXML. Microsoft has a lot of experience optimizing the performance of office suites and their file formats. I know from experience that those considerations tend to get lost in the standardization process.

      • My observation is that Microsoft has thought through some performance and reliability details to an impressive degree in OpenXML.


        While document reliability is of paramount importance, performance (as in speed) is virtually irrelevant. In terms of the overall time required to create or edit a document, a few extra seconds on opening or saving a file is just noise.
      • by Bob9113 (14996) on Friday May 26, 2006 @11:07AM (#15410264) Homepage
        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.
    • by Tim C (15259) on Friday May 26, 2006 @08:38AM (#15409213)
      Honest question - why do you, like so many others, assume that anyone who defends MS (or $otherHatedCompany) is a shill? Is it so hard to accept that other people have different opinions, and see things differently to the majority here?

      I'm not condoning or defending this particular study (although I have to admit, to me it smacks of "Company rubbishes competitor, talks up own product - film at 11"), I'm just getting a little weary of seeing all the calls of troll, shill and astroturfer levelled at anyone with an opinion that differs from that of the collective.

      (And before anyone says it, yes, that goes for both sides, Linux zealots and MS weenies alike)
      • by gatzke (2977)

        MS has a known history of paying people for grassroots positive PR online. That is where we got the term astroturfer from.

        So go ahead and defent MS on the merits. Convince me a .doc file is a better format. Tell me why we should not have open standards. Defend the indefensible. Most of us will poke holes in the silly arguments and some will call you names.

      • by zenhkim (962487)
        > Honest question - why do you, like so many others, assume that anyone who defends MS (or $otherHatedCompany) is a shill?

        Uh... why did the villagers assume that the little shepherd boy was lying the third time he cried "wolf"?

        Because by then he had lost credibility with them. It took only two times for that to happen. How many times has Micro$oft deceived the public? Let us count the ways....

        http://www.inlumineconsulting.com:8080/website/msf t.shilling.html [inlumineconsulting.com]

        More to the point, the author closes his art
    • by Amouth (879122) on Friday May 26, 2006 @08:42AM (#15409236)
      If you are refering to the refrence of a file format being slow.. then yes there is a diffrence between apps and formats but formats can be slow.

      a prim example is look at compressed archives.. say RAR.. if you look at the diffrence between a normal RAR archive and a Solid RAR Archive. the Solid archive takes all the files and treats them like a TAR ball so that you can compare like data and get better compression.. It doesn't take much longer to create the orginal file than a normal RAR archive which treats each file on it's own basis but when extracting or updateing you have to read through every file before the one you want in the archve when reading. and when writing you have to read all the ones before to evaluate the one you have and change it and then progress and extract and recompress every other file after it instead of just skooting them over when updateing a normal archive.

      both methods use the same compression methods and are of the same type and data types.. one gives you better compression but is and is faster to extract but is horid at random openings and updates where as a normal archive doesn't have the horid side affects but doesn't give you the higher compression or the speed in extracting.

      One thing MS has always been very good at is making MS Word fast. the load times are impressive and the save times like wise. forget about the stability for the moment and give them credit for being fast.. now i know TFA is fud and stupid but there might be a legit argument. MS knows how to make doc files fast, they designed them to be - if ODF wasn't as thought out for speed i could see it being an issue for anyone trying to implement it, and with some implementations there really is no way to make it faster.

      It is just something to think about. While the artical is dumb the argument could very well be legit. people should bash it just because it has MS writen all over it.
  • by Anonymous Coward on Friday May 26, 2006 @08:14AM (#15409025)

    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.

    • Seriously... So it takes twice as long when I save or open my document? Who cares? Saving is done seldom and/or in the background, and open time is dominated by the monstrous word processing app in question loading.

      MS makes it sound like the whole app will be somehow bloated and slowed down because of this, which is a clear deception.

      • It can't be any slower than putting up with Word on XP. I hit save and my machine locks on me for 5-10 seconds. Hangs, basically.

        vi rarely does that (on some 2 GB mail files) and LyX appears to save in the background, so I can go on editing. Whatever unix does, it seems to actually be responsive. LyX (and a lot of unix editors) keep an emergency save file, so I bet they are continuously saving so that it is not a big change when you want to update the "current" file.

        I just got a new dual Xeon to use a d
    • No, it matters! There's no way anybody could design a markup language that doesn't take any shortcuts in separating content from logic and still be worth it.

      Oh wait...it has been done. By Microsoft too, in fact. IE, Mozilla, and Opera are all capable of much more than ODF and at ridiculously high speeds.

      If you add to that the fact that the MS version actually has more useless features in it (which add to the parse time), I guess this is entirely a lie.
    • It's actually not a word processor (as your sibling correctly points out). ODF is simply a format and as such can't exactly be speed benchmarked. The study that this summary points to is about OpenOffice, which utilizes ODF but is not ODF in and of itself. All it takes is some way to more efficiently utilize/load the data. It's in the algorithms, not the format (unless it's a bloated format--which it doesn't appear to be from what I've seen of it).
    • 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.

      Agreed. We have converted ALL of our documents to ODF.

      Is it slower? To be honest, I have never noticed a difference. Nobody has mentioned it. Maybe it is slower, maybe it isn't. If it takes 5 seco

  • Yet again, MS is blaming the format for OO.o's failings. Hell, I don't like OO.o much myself. I like ODF though.
  • Well, at least OpenDocument has released something within the last couple of years.
  • by mustafap (452510) on Friday May 26, 2006 @08:18AM (#15409051) Homepage

    "Any performance limitations now will be resolved as Moores Law continues"

    Not that I like the argument.
  • Perhaps it isn't relevant, but I take anyone who attacks a competitor with a grain of salt-
    A better practice would be to praise your own product, and politely tell why it is better than the others. That is, if you believe in your product.
    Of course MS is going to go after OpenOffice- it means lost $$$$$ to them....
  • by oldosadmin (759103) on Friday May 26, 2006 @08:22AM (#15409089) Homepage
    Anytime Microsoft complains about OpenDocument, I just remember back to when they were on the Technical Committee at OASIS forming the standard. They then left that committee. If they truly cared about OpenDocument, they would have stayed on the TC and made changes to it.

    I see this as an attempt by Microsoft to slander this format and try to further their own semi-OpenXML format.

    --
    Jason Faulkner
    Eastern US Press Contact
    OpenDocument Fellowship
  • hypocrite
  • by revery (456516) * <charles AT cac2 DOT net> on Friday May 26, 2006 @08:24AM (#15409102) Homepage
    I can just see Microsoft's new slogan for Office 12:

    "Microsoft, saving your life, one microsecond at a time..."

  • Format Slow? (Score:4, Insightful)

    by jimktrains (838227) on Friday May 26, 2006 @08:24AM (#15409103) Homepage
    Since when is a format slow? I could write an interperter for the MS format that is 3x as slow as the ODF. What are they defining as unsatisfactory and on what kind of documents?
  • in RAM? (Score:3, Insightful)

    by Lord Ender (156273) on Friday May 26, 2006 @08:27AM (#15409122) Homepage
    You only need to write it to disk when you hit "save." When the document is open, and living in RAM, it doesn't even have to be kept in ODF!
    • This may seem odd but I've had to use word this week. I'm running on "windows server" attached to a nfs server. Man is it slow. Its a large document and it seems like word is accessing the disc all the time (which being a network drive is on the slower side).

      I'm not impressed with Word at all.
  • by dpbsmith (263124) on Friday May 26, 2006 @08:29AM (#15409140) Homepage
    ...is impossible, due to the therblig frammisating thingumbob.

    Well, actually, now that you mention it, a professor and his student did remove it, but you can't call it successful, because um, performance, sure, that's right, in our labs our very own scientific technical unbiased tests showed that because of ferthbernder sprocket-flange snap-toggle linkage, when you removed IE using the professor's techniques, it reduced Windows performance by a lot of percent. No user would accept this, any more than they would accept the reduced performance of WIndows on a year-old PC.

    We will now show you just how severe this performance problem is.

    Right here. In this very courtroom.

    With a faked demo^h^h^h^h^h^h^h^h^h^h a dramatic, animated illustration presented right on the screen of an actual PC.
  • whilst I know that in Oo it takes longer to save than in word (using the respective file formats) I don't care. If we say MS Word takes 1 sec. and Oo takes 5, then word is 5 times faster, but when it comes down to it - it's only 4 seconds once an hour... no consider how long it will take someone to rewrite all the documents when the format they've saved it in ceases to be and because it's closed they're stuck... that'll be a fair few hours... so really, Oo is about 8 million times faster because the ODF fo
  • by SpinyNorman (33776) on Friday May 26, 2006 @08:30AM (#15409148)
    If Microsoft are saying that they can't read XML documents efficiently then I guess we have to believe them, but if that's really true it says more about their lack of programming skill than the the difference between reading a binary vs text (or XML flavor #1 vs flavor #2) document on a modern processor.

    If a Windows-capable PC has enough oomph to render clippy in 3-D translucent splendor for Vista, then it's certainly fast enough to load an XML document.
  • by maggard (5579) <michael@michaelmaggard.com> on Friday May 26, 2006 @08:31AM (#15409152) Homepage Journal
    Yates went on to say that using MS formats left a fresh, minty feeing in user's mouths while every time an open one is used a kitten dies.

  • Translation (Score:2, Insightful)

    by Anonymous Coward
    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.
    Translation: Open XML is not a document format as such, it is an XML representation of how office sees the document, this makes it fast for Office, slow for anything else and unreadable for humans. We at Microsoft are really exited about Open XML...
  • by Tsu Dho Nimh (663417) <abacaxi&hotmail,com> on Friday May 26, 2006 @08:32AM (#15409164)
    One blogger, with one test protocol. Read George Ou's blog on it.

    He had a humongous spreadsheet (a couple hundred megabytes) and was tracking the load time.

    He whined about the memory OO takes, and didn't mention that MSOffice pre-loads its stuff on startup, so you are loafing MSOffice stuff whether you need it or not.

  • Uhmm... (Score:5, Insightful)

    by Egonis (155154) on Friday May 26, 2006 @08:33AM (#15409167)
    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
    • Re:Uhmm... (Score:3, Insightful)

      by 955301 (209856)

      I moved my office admin machine to OOO during version 1.x, and that thing is a 633Mhz P3. These guys are fools throwing poo. Nothing more...

  • by ceeam (39911) on Friday May 26, 2006 @08:34AM (#15409174)
    ODT format is basically a set of XML files packed into a ZIP archive. One of them is "the biggie" (content.xml) and others are for supporting it. Images etc are saved/packed in subdirs. Now - to open it, OOo apps should unpack the whole package and parse XML keeping all its contents in memory (presumably, but highly likely). Maybe not a big deal if all you handle is two page memo but keep in mind that OOo's spreadsheet and database(!) programs work the same way. And for something like 20-30 page specs sheet on a sub-1GHz machine OOo works noticeably faster when handling DOC format documents than handling its "native" ODT documents. Saving/autosaving can be a pain too (as you should dump all you document to XML and pack it. Unlike MSOffice where storage formats work as database).

    All in all - OOo's file formats are a nice and simple solution for exchanging reasonably sized documents (if you don't mind usual XML-namespace-hell structure) but for editing/working on larger documents/spreadsheets you may find yourself using MSOffice document formats (from within OOo). Pity they don't provide their own "scratch-pad/database-in-a-file" formats.

    So - for once, Microsoft is kinda right here.
  • RTFA. (Score:3, Interesting)

    by popeyethesailor (325796) on Friday May 26, 2006 @08:34AM (#15409181)
    I guess the loyal crowd has already reeled in +5 Insightful mods by railing against MS, but it might not be a bad idea to actually read the article.

    Mr.Yates says OpenXML has been designed with performance in mind, whereas ODF is not. A binary format such as .doc definitely has a few speed advantages over a XML format, hence it'd be good to have the replacement XML schema designed for performance.

    I wouldnt know if this was actually the case; however, it would be good to investigate if the claims were true. OpenOffice could very well do with a major performance boost. A lean,well-designed XML schema cannot hurt.

  • I mean, really. Is it such a shock that MS is trying to damage the reputation of a rival format? Actually, they're talking more about OpenOffice as an application rather than the ODF format, which is a very dishonest bit of FUD. I'm sure there will be more propaganda against ODF from the company we love to hate in the near future.

    Perhaps next they'll claim that ODF is so slow that it's causing Vista to be late to market.
  • so they've got their hands on the odt import filter for word then???

    cos this is the only way to do a format parsing test... and microsoft's xml format is purely a dump of their internal binary format and wrapping the info with xml tags... microsoft's format is mind bogglingly bloated by comparison with odt...

    odt concentrates on tagging up the structured information in sensible form, while microsoft's merely dumps the memory and horribly bloats out as a result... just like word does when saving to html...
  • MS App Tweaks (Score:5, Interesting)

    by Gallenod (84385) on Friday May 26, 2006 @08:35AM (#15409192)
    This brings to mind something that Microsoft did in the mid 1990's. When MS Word was trying to wrest market share from Wordperfect, Microsoft apparently coded speed bumps into Windows that only their programmers knew how to avoid. Microsoft then claimed that MS applications were "better" becuase they were faster, though we didn't understand that it was because of intentional handicapping of their rivals' software until they'd pretty much crushed WordPerfect in the market.

    It kind of makes me wonder if they'll try the same approach to make ODF look "slower," by optimizing MS apps to work with Open XML and fumble around with ODF files.

  • Oh noes! (Score:3, Insightful)

    by Sj0 (472011) on Friday May 26, 2006 @08:38AM (#15409208) Homepage Journal
    Oh noes! That document took 5.3 seconds to load and 10.2 seconds to save! Sure, I've been working on this document for 20 hours straight, but that's a LONG time to wait!!!
  • Oh Right... (Score:5, Insightful)

    by Greyfox (87712) on Friday May 26, 2006 @08:45AM (#15409255) Homepage Journal
    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 [stfu.se] and go back to pushing your poison kool-aid on unsuspecting consumers before Apple eats your lunch.

    • Re:Oh Right... (Score:3, Insightful)

      by Al Dimond (792444)
      On the other hand, when they came up with Windows NT they implemented the Win32 API in the kernel to avoid the extra context switches required by a more userland-centric GUI (not to mention an X-style client-server model). They traded off flexibility and security (though, to be honest, security is hard to get when you require as much hardware access as GUIs do these days) for performance because they found the performance hit too much to bear, and at the time they just might have been right.

      As some other p
  • by kel-tor (146691) on Friday May 26, 2006 @08:57AM (#15409341)
    http://www.groklaw.net/article.php?story=200511251 44611543

    using a text editor, would you rather try to fix a bug in an odf or ms xml file?
    MS XML
    <w:p>
    <w:r>
      <w:t>This is a </w:t>

    </w:r>
    <w:r>
      <w:rPr>
       <w:b />
      </w:rPr>
      <w:t>very basic</w:t>

    </w:r>
    <w:r>
      <w:t> document </w:t>
    </w:r>
    <w:r>

      <w:rPr>
       <w:i />
      </w:rPr>
      <w:t>with some</w:t>
    </w:r>

    <w:r>
      <w:t> formatting, and a </w:t>
    </w:r>
    <w:hyperlink w:rel="rId4" w:history="1">
      <w:r>

       <w:rPr>
        <w:rStyle w:val="Hyperlink" />
       </w:rPr>
       <w:t>hyperlink</w:t>
      </w:r>

    </w:hyperlink>

    </w:p>
    OpenDocument
    <text:p text:style-name="Standard">
       This is a <text:span text:style-name="T1">

       very basic</text:span> document <text:span
       text:style-name="T2"> with some </text:span>
       formatting, and a <text:a xlink:type="simple"
       xlink:href="http://example.com">hyperlink
       </text:a>

    </text:p>
  • by VincenzoRomano (881055) on Friday May 26, 2006 @08:58AM (#15409347) Homepage Journal
    There is something true in that study [zdnet.com], indeed.
    Personally I already have seen this kind of numbers, even though I've never minded to measure them.
    Why? Simply put, because it matters very little.
    Compared to Windows 3.11, Windows XP needs 100 times more disk space, 10 times more RAM and 10 times more time to boot.
    Compared MS to Word 5.5, MS Word 2003 if slower and bigger.
    Today I wouldn't revert back to Windows 3.11 and would not choose Word 5.5. What'd be the most important features expected in a document file format? In my opinion:
    1. compactness
    2. openness
    3. flexibility
    No "access performances", though.
    Because the time needed to load a document, when you do real office work, weighs by far less than the time you spend on it while working.
    And when someone sends you a file written with a different version of the software or even with a different software, how much time do you spend to make that file readable and printable?
  • by fph il quozientatore (971015) on Friday May 26, 2006 @08:59AM (#15409355) Homepage
    Here [unipmn.it] is a fast new algorithm to compress XML in such a way that browsing and searching the tree can be done without uncompressing it. This should make Word definitely faster when handling ODF. I really think Microsoft should start implementing some of this stuff instead of whining and complaining.
  • by The OPTiCIAN (8190) on Friday May 26, 2006 @09:22AM (#15409530)
    This reminded me of this paper [labri.fr], "The Psychology of Learning". In it the writer describes the act of people who don't want to learn new things: "As long as everybody around them use tools, techniques, and methods that they themselves know, they can count on outperforming these other people. But when the people around them start learning different, perhaps better, ways, they must defend themselves. Other people having other knowledge might require learning to keep up with performance, and learning, as we pointed out, increases the risk of failure. One possibility for these people is to discredit other people's knowledge. If done well, it would eliminate the need for the extra effort to learn, which would fit very well with their objectives."

    This issue is about Microsoft defending their turf rather than not wanting to learn something new. But it's basically the same motive at work: find ways to undermine the new to benefit the old.

    It goes on, "This model of learning also explains other surprising behavior that I frequently observe. I have seen novices in software development with knowledge of a single programming language explain to experienced expert developers why their choice of programming language was a particularly bad one. In one case, I talked to a student of computer science who told me why a particular programming language was bad. In fact he told me it was so bad that he had moved to a different university in order to avoid courses that used that particular language. When asked, he admitted he had never written a single program in that language. He simply did not know what he was talking about. And he was willing to fight for it. With respect to programming languages, negative opinions about a language that a person does not know, are usually based on very superficial aspects of it. To people obsessed with performance lack of such in a programming language is a favorite reason to advocate its eradication (even though performance is not a quality of a language, but of a particular implementation)."

    The positive lesson to take away from this is the MS is undoing itself. It's turning to cheap, nasty, suit-driven mentalities to defend its turf rather than the old days when it would just go out and write something new and nasty. It's become an unwieldy beast. I read about the Vista delays yesterday and briefly thought "Will anyone notice - who uses Windows these days". To an extent it shows what a bubble I live in. But it's true - *all* of my regular contacts use linux, freebsd or mac os x. As they should. After all - friends don't let friends use Windows.
  • by popo (107611) on Friday May 26, 2006 @09:51AM (#15409717) Homepage

    Because "free" still means more to me than an additional 1.7 seconds.
  • Eh? (Score:3, Insightful)

    by belg4mit (152620) on Friday May 26, 2006 @10:05AM (#15409832) Homepage
    If it it were technically true, so what?
    Why the hell does a text editor need to block the UI while writing to disk?
  • by Fedarkyn (892041) on Friday May 26, 2006 @10:05AM (#15409834)
    At tech-ed 2005 here in Brazil I saw one of MS evangelists showing a table comparing speeds for MS office (don't remember the version) and openoffices showing diferences od 20x or more...

    I use both offices suites at work and at home and the speed difference is in the order of 2x at most for the first loading of the program and almost no difference after this (anything below 1 second is just "fast enougth" for me). And my computer is rather outdated.

    I think ms Office a fair software, not worth the price, that's really expensive in Brasil, but they don't need to lie this way to sell it...
  • by mpapet (761907) on Friday May 26, 2006 @11:56AM (#15410671) Homepage
    MS did this right again.

    They deliberately confuse the application with the file format.

    Psycologically reinforcing the perception that everything in a computer is vertically oriented and "incompatible" unless it comes from our application.

    They understand the immense threat that a viable alterative (file format in this case) presents. PHB gets idea, "If this is iteroperable, gee I wonder what else is?"

    Beautiful.

Time to take stock. Go home with some office supplies.

Working...