Slashdot Mirror
OpenOffice Bloated?
cygnusx writes "ZDNet's George Ou has been writing a series of posts about Open Office bloat. Includes some interesting system usage comparisons" From the article: "Even when dealing with what is essentially the same data, OpenOffice Calc uses up 211 MBs of private unsharable memory while Excel uses up 34 MBs of private unsharable memory. The fact that OpenOffice.org Calc takes about 100 times the CPU time explains the kind of drastic results we were getting where Excel could open a file in 2 seconds while Calc would take almost 3 minutes. Most of that massive speed difference is due to XML being very processor intensive, but Microsoft still handles its own XML files about 7 times faster than OpenOffice.org handles OpenDocument ODS format and uses far less memory than OpenOffice.org."
I dont know how you got the opposite results.
I installed OO 2.0 on my machine to check the updates, and to see if its speed is up to snuff. Issues with compatibility are gone but it is more than twice as slow while opening files. (I'm not using quickstarters for OO or MSO).
Heck since I'm reporting these results, I MUST be a microsoft shill too I guess.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Office uses zero MFC. Most of the older bits is Platform SDK C, and is a b*tch to maintain, and the newer parts are C++ *but not* MFC -- I understand the Office team has its own lightweight frameworks, similar to ATL.
Go somewhere random
Openoffice.org is a C++ app. It uses java for some scripting, but everything else is C++.
He provided the test data here and here
><));>
I recently purchased an iBook G4 which came with a trial edition of Office.Mac (or whatever it's called). I used it for the 45 days of the trial and then switched to "OpenOffice.org for the Mac," otherwise known as NeoOfficeJ. The only thing I've noticed thusfar is that Neo takes about 1.5 times longer to run initially, and it seems to take longer to save files. Other than that I really haven't noticed any other differences in performance.
Hmm. I've been running MS Office 2003 for over a year and have yet to experience a single crash with Word or Excel. I've had Outlook freeze up numerous times, but virtually all of those problems have their roots in our Exchange server (and the seriously mismanaged overload they've piled on it.)
John
He is already anti-Open Document http://government.zdnet.com/?p=1723 and heavly pro-Microsoft http://blogs.zdnet.com/Ou/ so this is not unexpected.
Not to argue about whether or not OOo is more bloated than Office, but George Ou has always seemed to be ranting pro-MS and putting forth statements like this just to get the reaction.
Here's his webpage
And his other ZDNet entries
Also, you might want to check out the comments already posted to his review of OOo beta2
Honestly, I want to love Openoffice and to advocate it... I have worked in finance on excel, dealing with huge huge spreadsheets and many graphs... Have you tried to plot a 10 000 points graph in OOo Calc vs excel... in excel it is done in less than a second... In OOo the application will freeze for half and hour before slowly starting to display the graph. Cherry on the cake it will conviniently try to write "ROW" under each point in a huge ugly font. After that, changing the data means of course waiting half an hour again because the chart is updating. OOo calc simply doesn't do the job, how hard I wish it would.
\u262D = \u5350
Just to attempt to forestall all the Java posts - Openoffice.org is written almost entirely in C++, not Java.
Disable Java in the options and it starts in 1-2 seconds on the same machine.
Somewhat off topic but pertinent ENOUGH... Good God man! Thank you! The Java tab in the options dialog was incredibly easy to find but for some reason I just breezed right over it. Unclicking that little devil's box just dropped my start time from 15-20 seconds to 1. I know it likely has nothing to do with the working data that this "benchmark" tested, but it sure shows how good an idea it would be to transition the Java dependency on over to native code.
"This is Zombo Com, and welcome to you who have come to Zombo Com" - www.zombo.com
OO.o is written in C, not Java.
Go to the Options and uncheck the Java option (Use a java runtime environment). After this, OpenOffice.org start like a breeze...
Read this comment for a nice description of why that is not ad hominem.
Your slur on his 2 digit ID, however, is completely off topic. Google for "petard, hoist upon".
Infuriate left and right
IIRC there was an article not too long ago that explained that the main difference between Office and OO is that Office makes extensive use of lazy loading, while OO essentially hammers through loading every library it may need, which not only thrashes the disk once on initial load, but again as you (likely) swap out memory pages. My recollection was that this lack of lazy loading had something to do with cross-platform compiling and linking issues, as well as MS having extensive resources to put into optimizing Office loading that OO did not. My understanding is that Sun hasn't exactly dumped developer time into OO, either, and I believe the focus of this release was compatibility and.
Typically people solve this problem by preloading a bunch of the relevant libraries at startup, a strategy both MS and OO attempt to employ (viz OfficeStartup and OO QuickStarter). I used to detest that, but if I had 1 or 2GB or RAM and wanted to rely on OO, I might not find it so bad. I think an interesting addition to this comparison would be to see how OO fared with QuickStarter enabled, and what drain that placed on the rest of the system. Likewise disabling the JVM loading.
but even I can see that OO.org runs laps around any MS product for my uses
You've got to be kidding me. OO has never been faster than any version of MS Office I have ever tried. Without that "booster" application sitting in your system tray the individual applications take usually about 2x as long to load and be in a usable state as the equivalent MS Office application.
Now, on to some real numbers. I'm timing this with my watch so you'll have to forgive the ~1 second resolution. I perform each test several times to ensure that disk I/O doesn't taint the numbers.
A random excel spreadsheet on my desktop that calculates some manufacturing costs.
XLS format - 1980 kb
Opening in Excel XP (this includes the time to load excel)
Less than 1 second
Opening XLS file in OO (Calc already loaded)
5 seconds
Ok. To be fair we should save the spreadsheet in OO format so the converter isn't required. Let's test save times first though.
Save as new XLS file under Excel XP
3 seconds
Save as new XLS file in OO
3 seconds
Save as new native file in OO
4 seconds
Ok. Let's see how long it takes OO to open a document saved in native format.
Open ODS file in OO (Calc already loaded)
7 seconds (not surprised - XML processing is sssllllooooowwwww)
And finally, on to memory usage with said spreadsheet loaded:
OO Calc - 67 meg
Excel - 15 meg
I won't even mention the issues with things like the noticable delay between the time you click the menu and the time it appears. Don't get me wrong - OO 2.0 is a nice office suite but don't claim it "run laps around" MS Office. That isn't true by any stretch of the imagination.
XML is a data interchange format. We've finally arrived at the era where apps can interchange data in XML without (necessarily) being trapped in a proprietary data format. But that doesn't make XML suitable for internal data representation. Apps should use internal data formats that support their native performance, and serialize data objects to XML for interchange, including storage. Using XML internally when performance thereby suffers is the bad kind of lazy, bad design that saves development time at the manifold expense of user time.
--
make install -not war
"You clearly don't know what an ad hominem attack is."
The GP does indeed appear to understand the subject. I think the confusion lies in the fact that there are various types of ad hominem attacks. In this case, this is what's known as a circumstantial ad hominem.
The wikipedia article explains this well. If you believe the wikipedia article to be incorrect, you may want to take the time to edit it.
"But when Ou, who has a long and easily verifiable history of writing articles that disparage open-source software, says the same thing, his words should be taken with a generous pinch of salt."
Ironically, you have made an ad hominem attack yourself. From the wikipedia article:
But I'm not surprised that you're incorrect, since Anonymous Cowards usually are. ;-)
Sitting in my day care, the art is decopainted.
That's not true at all. While OpenOffice is "only" maybe 5-6 years old now, it is built on top of the older StarOffice codebase, which has been in development since the mid-1980s. It's not like they started from scratch a few weeks ago...
http://en.wikipedia.org/wiki/StarOffice
You can't deny the fact that MS has had about 10 years long[er] to get MSO right than the OOo people have had to get OO right.
Are you joking? StarDivision was founded in 1986, and some code found in OOo goes back almost that long. StarOffice was created in 1994. Depending on how you count, I would say that StarOffice and OpenOffice are within a year or two of each other in age.
Two years until OOo is as good as MSO? You're dreaming! I'll take that bet.
Personally, I use Gnumeric for all my spreadsheet tasks, and I eagerly await the day when Abiword doesn't randomly crash when a document contains footnotes.
Hidden code, you say? Before you go off accusing Microsoft of a Consent Degree violation, perhaps you should be a bit more careful about what exactly you're comparing. It is extremely important when you try to compare "memory usage" on different Operating Systems that you are actually comparing apples to apples. And since you didn't cite the source for your "7.10" and "9.81" numbers above, I doubt you really understand what you're measuring.
If you're using Task Manager, for example, you will by default only see "Mem Usage" which reports the physical memory (i.e., the "working set") consumed by the process. Even though this metric includes both private and shared pages (i.e., shared code and data segments of DLLs are charged to each process here), it does NOT include pages which still reside on disk (either in the executable images, memory-mapped files, or the system pagefile.
Another common memory statistic from Task Manager is "VM Size" (you have to add it to your column view by "View->Select Columns"). "VM Size" tallies private virtual bytes consumed by the process. Private means that this quantity does NOT include shared/shareable pages like DLLs and memory-mapped files. "VM Size" is sometimes smaller than the "Mem Usage" precisely because shared pages aren't counted. This causes a large amount of consternation to those who don't understand what is being reported, because they expect physical memory usage to be smaller. "VM Size" is the equivalent of the process's page file allocation, since shared pages by their nature are already backed up on disk elsewhere.
Another common memory usage metric in Windows can be obtained from Perfmon (perfmon.msc, the Performance MMC snap-in). From this tool, you can view "Virtual Bytes" of each process, which is the amount of reserved virtual memory for the entire process, including shared pages. It is equivalent to "VM Size" from task manager PLUS shared virtual memory.
So, as you can see, it is not altogether obvious what is being reported unless you really understand the details of memory management on the underlying OS. Before comapring application memory usage across platforms, you need to be sure you're using comparable metrics!
To be blunt, the guys who wrote the Excel GUI got an "A" in computer science, but the guys who built the calculation engine only got a "C+". To be a truely great spreadsheet, Excel must:
Any engineer who gives me a calculation done in Excel using circular reference calculations had better be prepared to get his butt roasted. I've had 10Mb files modelling a copper smelter that converged to a wrong answer - that's unacceptable given that the same calculation saved as a 1-2-3 file converged to a correct answer in 10 seconds using Lotus 1-2-3.
-AD
I had a user with a corrupt Excel spreadsheet. She wanted me to dig up a tape backup from March to restore. Instead I opened it in OpenOffice, and saved it back to Excel format, and voila, it mirculously opened in Excel again. So, in this instance, at least, OOo was much faster. :)