After interviewing members of Koffice’s team, Updegrove now interviews OpenOffice.org’s team. “Today, it’s the turn of OpenOffice – the other well-known open source implementation of ODF, and the most implemented of all software packages that support ODF. The interview that follows is with Louis Suarez-Pots, OpenOffice’s Community Manager, and John McCreesh, Marketing co-lead.”
No doubt, Openoffice has evolved into a robust office suite rivaling even microsoft office. But opening OpenOffice.org takes much longer than say opening Abiword or KWord in Linux. I think making openoffice faster to load should be one of the aims of the oooffice team.
I also wish they’d seperate it out a bit more so that each program was a seperate executable. It’s a bit unweildy having one executable, and in corporate environments they might not want one of the OOo apps installed or available due to conflicting/duplicate software.
“But opening OpenOffice.org takes much longer than say opening Abiword or KWord in Linux. I think making openoffice faster to load should be one of the aims of the oooffice team.”
This is am insane criticism, it bugs me to no end when I hear this complaint. You know what the difference in loading is? Seconds! Wow, you would think these people were complaining about something.
Umm… I their defense, when I fire OO 2.0 on my PII/366 Slackware Laptop (with 256MB) , OO takes ~40 second to start. Heck, even on my home dual – dual core Opteron workstation (with 4GB) OO still takes around 6-7s. (Warm start: ~3s)
Don’t get me wrong, I can live with it… but it will be nice, if I could load OO on my laptop in less then 30 seconds.
Gilboa
Few seconds can make a huge difference depending on your usage pattern.
Many times office documents are used as mere reference in a readonly mode just like html and pdf.
Now, try to browse through say 30+ documents having to wait your share of seconds every time you need to look for 3 words or a picture.
This is seriousely disturbing your workflow.
The way OOo slow document loading speed (startup + open time) disables some typical workflows, makes quick loading a feature that OO.org sorely lacks.
A gues a fast, standalone viewer would greatly relieve this burden.
That’s why I put high hopes on KOffice. Their recent ODF compatibility level is very prommising and KWord/KCalc KPART is exactly what I’m talking about.
I can see providing access to all platforms being a bit tricky with the interwined Java code. I’ve been strongly against Java in the OOo codebase because of lacklustre java support on more alternative OSes and the horrible and intruding (and insecure) Java implementation in Windows.
Are you saying that OpenOffice.org is developed using Java language ?
No wonder it is so sluggish to start.
It’s not entirely Java, just bits of it (the wizards, and pretty much all of the Base program). In my experience, this does slow down start up a little. If you go into the options, and theres a tick box to disable the use of Java, you might find that it cold starts marginally faster.
You do realise that OpenOffice.org java modules can now be successfully compiled and used with GCJ – so there is no need for relying on SUN’s blessed JDK/JRE as the opensource java already works nicely.
FYI,
The OpenOffice on my Fedora Core 4 & 5 Linux machines (both i386 and x86_64),
uses the native and open GNU gcj compiler.
http://gcc.gnu.org/java/
While it’s performance are still a bit sluggish, in time, it perform better
then SUN’s JVM.
… Sorry about my Piglish… Me seem to need a cup of coffee ASAP.
Yes remove the Java crap please.
It makes the system slow, uses much resource, Java is not available on all systems, it’s not open-source yet and anyway I don’t like Java at all (apps, applets, JSP, etc…).
The GCC version of Java is open source, and as someone above said, it is already good enough to run OOo.
Now you can complain about it being slow and using too much memory, but frankly if those are concerns than OOo is not the office suite you should be using in the first place. Most of it is C++ code and it is horribly bloated and inefficient.
> Most of it is C++ code and it is horribly bloated and inefficient.
Agreed. A few months back I looked at the module interdependency diagram for OpenOffice. I can’t find a copy now, but from what I remember, it was a very bad mess of interdependencies. It’s gotten better since the 1.0 days, but it’s still a bundle of spaghetti. When you start up OpenOffice, everything loads, whether you need it immediately or eventually or not or even not at all. If things were cleaned up a bit more, you would only need to load the minimum when you started up OpenOffice and incrementally load the rest of the less critical stuff in the background and load the rest of the stuff (that didn’t require on demand response time) only when asked for. This would dramatically increase the startup time and memory footprint. The OpenOffice team has already done some of this work in OO 2.0, but from my last reading (a few months back) there seems to be a lot more places where this can happen.
Agreed. The Java part is actually not the cause of the slow startup.
Don’t get me wrong, I think OpenOffice great. In terms of features, it’s second only to that expensive, Windows-only thing that Microsoft do.
The trouble is that it’s big, bloated, and complicated, and if we’re honest, it’s pretty slow. This slowness is particularly highlighted in Linux, where a combination of the kernel, GCC and the way linking is done means that it’s quicker to load up a document in MS Word via Wine than it is in OO.o.
This problem dates back to the sheer age of a lot of the code. OpenOffice was originally StarOffice. When StarOffice 1.0 was released, KDE was in its infancy, and Gnome didn’t exist. The developers had to include a lot of their own “desktop platform” code that is simply not needed these days. That’s why OO.o doesn’t even *build* on 64-bit systems, let alone run. I read somewhere that OO.o contains 5 million lines of code. The *entire KDE desktop environment*, which is also written in C++, uses just 3 million loc.
What needs to happen is that instead of pressing on and trying to work around the flaws, Sun needs to step back and see how they can get rid of as much of the legacy code as possible. Keep the features that it has as much as possible, but re-write the GUI so that it uses native toolkits, like Abiword does. Or decide on one toolkit that runs on many platforms, like Qt or GTK+. Split the suite up into separate applications, like MS Office and K-Office.
All this will take a lot of work, but it is possible. It happened with the Mozilla project. A few yaers ago it was big and bloated and contained a lot of legacy Netscape stuff. Then Firefox (or Phoenix as it was then) came along and showed everyone a faster, slimmer, better version of the browser. Pretty soon the Mozilla Foundation re-wrote their long-term plans and concentrated on Firefox instead. And it’s been a huge success.
Sun: be brave, bite the bullet, and do it. The result will be worth it. Even if it contained not a single new feature, a faster, slimmer, better looking OpenOffice 3.0 would attract a lot of open-source developers who are, right now, frightened off by the sheer complexlity of version 2.
That would indeed be nice if sun does do that but we can all dream. I doubt that will happen.
Hear hear! I would definitely use OOo over MSO if it were as light and fast and pretty looking as any of the MSO’s 2000~2007. I once had a 300MHz PII temporarily and with a basic Win98 install on it, I could open Word 2002 instantly, no splash. Office XP and below are light and quick, they did add a lot of bloat in 2003.
Desktop apps slowness is in not permanently connected to Linux.
As an excercise download a trial version of TextMaker for linux, a featurefull commercial wordprocessor. It was written from scratch with linux in mind and it shows. Is starts up almost instantly ,and this from coldstart!
I know a several examples of QT based commercial apps that leave even their KDE equivalents in the dust.
I’ve no idea how did they achieve that.
I do agree the OO code should be cleaned, but I’m sure Firefox is right
example: At least in my experience, the Seamonkey is still faster then Firefox and eats
less resources.
However, the Mozilla example is a much better example:
When Netscape released their NS 4.x code (1998?) it was a mess; The Mozilla
project (and then the Mozilla foundation) had to rewrite/replace most of the
code; In return, the Mozilla 1.0 was far better then Netscape 5.0 could ever
be.
G.
Book publisher “In Pictures” has made some of their OpenOffice.org 2.0 (Base, Calc, Impress, Writer) books available for free download.
http://inpics.net/
Quite the reverse with Firefox. It didn’t make many changes to the engine part of mozilla (xpcom+xul) and was mere UI “debloatization”. Most advances FF made in terms of rendering and leanness are inherited by mozilla suite which is as responsive as FF nowadays.
This actually proves that incremental changes when properly planned can put a downward spiral projects back on track.