OSNews

Depending on who you talk to, OpenOffice.org's sluggish performance can be attributed to:

1. The kernel
2. GCC
3. Glibc
4. TWM
5. Terrorism
6. Phase of the moon

I think we'll get a whole lot further when they admit it's just a hulking great sloppy codebase that's in desperate need of efficiency and cleanups.

The finger-pointing doesn't really work. If it's the kernel's fault, how come MS Office starts up and runs much, much faster under WINE? And if it's GCC's fault, how come GCC can be used to build fast programs?

Actually, I did some tests recently and OOo started in about the same time it took to start MS Office in Wind (about 24 seconds, which is too long IMO).

Also, we have to make a difference between the time it takes to start OOo, which is a bit long (but can be solved with preloading, I believe) and the actual performance of OOo while using it, which is fine on modern hardware.

In SUSE 10, ooo 2 starts in about 8 seconds on a amd athlon xp at 1900+. So I guess a bit of OS integration doesn't hurt after all. SUSE does a lot of preloading.

I think openoffice is faster because it does a lot more under the hood as MS-Office.
I believe (but I'm not sure) that it is slower because of UNO. Please correct me if I'm wrong with that. UNO is a little bit like RMI, or CORBA.
It
* allows external programm to call function from the office suite, locally or via network (not only addons).
* allows scripting languages to access function of openoffice.
* allows to easily bundle plugins for all platform where openoffice is supported
* simplify porting Openoffice to other platform more easily.

This is nice because it makes openoffice more portable. It also allows to write addons in a lot of scripting languages, thats much easier as plain C++.

I programmed an java programm using uno, and I think that you lose always some time then getting UNO objects, and using functions from the suite. Perhabs Microsoft office is faster because of that (and also because some components are already preloaded). But I also believe that UNO is a cool feature.

Care to show some proof on why "the kernel and gcc both suck"?

If Darwin is so much better how come it's threading sucks ass compared to Linux. Want proof? Run MySQL on both Darwin and Linux and see who gets destroyed.

Have you ever seen the infamous AnandTech OS X (darwin) benchmark? Or even this guys? http://sekhon.polisci.berkeley.edu/macosx/
You will find G5 on Linux is way faster than G5 on mac, and his linux kernel is not optimized.

So, they were right all along! Google really is interested in MS Office alternatives, even if they continued to deny it.

More like their continued denials started to look like they didn't care about the community, so they put some programmers on the project to show that they do. Since they certainly have the programmers, good for them!

Google is a business and DOES NOT CARE ABOUT YOUR COMMUNITY, they are not UNICEF.

What they want is to force Microsoft to battle on as many fronts as possible.

If Open Office got very competitive in terms of feature parity with the current and upcoming MS Office product, it would force Microsoft to allot more engineering time and more marketing resources to that product, pulling those workers away from other work, like Vista, the new IE, the new Media Player, the new Anti Spyware, etc.

It's actually a VERY SMART thing for Google to do as a competitor to Microsoft, make them spread their resources thin.

Life Unicef did ever care. Funny that you believe the bureaucrats are any better.

didn't you hear? It's gotta be one or the other.

That is true. Google doesnt give a damn to open source. Just look at their current support for linux.
Their simple goal is to compete with MS.

I think Googles intrest in OOo has more to do with ODF than MS. If ODF is adopted as an industry standard it would open up a HUGE market that is perfectly aligned with Googles core competencies.

Then why does this story make me feel all warm and fuzzy?

It's actually a VERY SMART thing for Google to do as a competitor to Microsoft, make them spread their resources thin.

Your argument is recursive. Google throws bodies at OO detracts from their core compentancy as well.

"Your argument is recursive. Google throws bodies at OO detracts from their core compentancy as well."

Isn't revenge suppose to be sweet or something? Yeah! Google proably isn't doing what they're doing so that the rest of us can feel good. But I wouldn't be surprised to find out that IBM still hasn't forgotten what happened with OS/2 and Microsoft.

It doesn't go from 30 seconds to 2 seconds though - that's just because it's already cached. There's a lot of "tips" out there that do very little, but people restart OOo after applying them, and it loads straight from RAM, so it appears to be miles faster.

In my experience, disabling Java improves OOo's startup by two or three seconds, but that's out of 15. So yes, it's welcome, but in no way does it go from 30 to 2 :-)

In my experience, disabling Java improves OOo's startup by two or three seconds, but that's out of 15. So yes, it's welcome, but in no way does it go from 30 to 2 :-)

Yes same experience here.

Making it optional is one thing, removing it altogether is another. I personally know Java, so having Java support in OO.o for writing macros means far more to me than you having a few extra second of start up time. If Java support in OO.o is a problem you can disable it, in fact that's even an option when you install OO.o.

The problem is that Java is used for more than just macros.

For example: In Ubuntu, OpenOffice's help system is missing altogether because of its dependency on Java.

Also, I've heard that accessibility features in OpenOffice are dependent on Java as well.

It seems to me that drawing a line in the sand between which features in OpenOffice should use Java (such as macros in your example) and which shouldn't (such as help and accessibility in my example) is a very difficult thing for OpenOffice developers to do. Having support for Java gives developers a crutch that they may start to lean on too frequently.

Java would not be as much of an issue in Star Office or another closed product. However, one of the main features of OpenOffice is the fact that is is under a Free license enabling it to be bundled with distros like Debian and Ubuntu. This point becomes moot when the product depends more and more on a non-free component.

For example: In Ubuntu, OpenOffice's help system is missing altogether because of its dependency on Java.

No it's not.

I *wholeheartedly* agree. Non-free components have _NO_ place in a free office suite. Maybe I'm paranoid but I really think that the only reason Sun has supported OpenOffice development all along is to build the Java-using marketshare so that they can twist our arms later with Java (possibly charge for it and/or file lawsuits against open implementations of it forcing us to use their implementation). Furthermore, I have never heard a good technical argument for OpenOffice depending on Java.

Yes, I realize Java is not required to install OpenOffice but keep in mind that OpenOffice sans Java results in less functionality.

For more information about the perils of using Java in Free Software, see http://www.gnu.org/philosophy/java-trap.html

On Fedora Core 4, OOo 2.0 uses gcj instead of java.
http://gcc.gnu.org/java/

I *wholeheartedly* agree. Non-free components have _NO_ place in a free office suite. Maybe I'm paranoid but I really think that the only reason Sun has supported OpenOffice development all along is to build the Java-using marketshare so that they can twist our arms later with Java (possibly charge for it and/or file lawsuits against open implementations of it forcing us to use their implementation).


I am surprised you didn't break your leg jumping to such a ridiculous conclusion

There is an OOo project to create a new chart engine.

http://graphics.openoffice.org/chart/chart.html

I agree with you about the current state of graphing capabilities in OOo, and so do the developers at OOo.

IMO this would be one of the best places to really improve OOo, and I hope that now that 2.0 has been released a lot more can be done. I agree with many of the other posters that startup time and memory usage could certainly be improved, but graphing capabilities and database usability (for the casual user) are areas that would truly enhance the appeal of OOo to a wider audience.

Another bonus to the new chart engine/architecture is that it could be used by Base for reports as well as Calc (a serious leg up over Access).

Sould have used LaTex

And this one, which runs on Linux, OS X, and Windows:
http://soft.proindependent.com/qtiplot.html

Haven't tried it much yet, since I primarily use Matlab.

and throw!

"It's not a lie that the kernel DOES have a say in how OO.o performs, preemption, CFQ scheduler even -ck patch help alot. I wonder what distros use Preemption for low latancy which helps OO.o but it's not the hole reason why it starts up slow, 8 seconds is good going for nothing preloaded and natual start time."

You're correct, there is some negligible impact due to the kernel. But OpenOffice performs slower than MS Office on Windows as well, so it would appear that the kernel has little to do with the gap.

Please do some reading on these Linux kernel technologies. They are fascinating, but only if you understand them. For one thing, kernel preemption has nothing to do with the issue of OO.o performance. In fact, Con Kolivas himself (maintainer of -ck) doesn't think that full preemption is beneficial on the desktop, even suggesting it might be an overhead. The jury is still out on whether voluntary preemption is worth its space in memory.

CFQ is a priority-based, timeslicing I/O scheduler. You probably meant to reference the staircase process scheduler if you are a -ck fan. But OO.o's problem is not that it doesn't get scheduled efficiently.