Is getting faster? - Ninja

Is getting faster?

Posted by Andrew Z at Wednesday, May 28, 2008 | Permalink

Some complain is slow and bloated. With each release there may be dozens of performance improvements, but there are also new features, some of which may slow things down. This the natural balance in software development, but in the end, what is the net effect on performance from one version to the next?

The benchmark

We need a good benchmark to produce good data, but what do we measure? Let's assume the most common operations are starting, opening a Writer document, scrolling from top to bottom using the down arrow, exporting the document, and closing both the document and

This benchmark automatically performs these 5 operations while taking precise measurements. The tests are repeated because of inevitable noise in the results. The benchmark performs 10 passes where each pass begins with a reboot to test cold start performance. Cold starts are slower because hard drive information is not in cache memory. Each pass consists of 10 iterations, of which most iterations measure warm start performance. Warm starts are faster because the operating system has cached the hard drive information in memory. You may notice is faster the second time you open it. In this benchmark, testing each version of yields 500 measurements. With 11 versions, that is 5500 measurements.

The specific Writer document tested is the ODF_text_reference_v1_1.odt. All tests are done against unmodified vanilla builds from the web site.

Test environment

The modest test machine is about three years old. Of course, newer machines should perform better.

  • Linux distribution: Fedora 7
  • Kernel: Linux
  • Java: Sun 1.6.0_03
  • CPU: AMD Athlon XP 3000+
  • RAM: 768 MB, DDR 333 (PC 2700)
  • HDD: Maxtor 6Y080L0, 7200 RPM, 80 GB
  • Filesystem: ext3
  • Default settings in (no optimizations)

The results startup performance is critical to the overall perception that the application is quick. The startup process involves many steps including loading the application into memory, resolving the linking of symbols, initializing fonts, reading configuration files, initializing the Java runtime, checking printers, checking for software updates, and importing any documents. At different points the startup process may stress the hard disk, CPU, memory, and network interface.

A 2003 document called "Q" Product Concept described these goals for 2.0 performance:

SO/OOo will improve its performance in four areas that are especially important to customers. The two most visible areas of improvement will be decreasing the Startup Time and Document Open/Save Time.

With startup time, they certainly succeeded as you can see in this boxplot depicting application startup times after a cold start, meaning directly after a reboot of the operating system without the benefit of caching. The single jump from version 1.1.5 to 2.0.0 slashed application startup time a dramatic 43%. (In all charts on this page, smaller is better.)

There are two competing laws at work: Moore's Law and Wirth's Law. Moore's Law basically states, You can cheaply buy a doubly fast CPU in two years. In contrast, Wirth's Law states that each new release of a software program grows more complex and slower to cancel out the effect of the faster hardware. In other words, today's dual-core CPUs run Vista about as fast as an ancient 80286 (20 years ago) running MS-DOS 3.1. It's unrealistic for software to be faster over time: newer software does more work. When a newer version performs more quickly, it generally means the previous version was inefficient. The goal is to delicately balance performance, new features, and development resources.

In the 1.75 years since the fast version 2.0.3 release, startup time has crept up a modest 0.70 seconds to version 2.4—. That still leaves a 20% improvement over 2.6 years from version 1.1.5 to 2.4. So much for Wirth's Law: it's more of a guideline than a law anyway.

D300m3 is short for DEV300_m3, an early 3.0 developer's snapshot— even older than the 3.0 beta. Performance may vary in the final 3.0 release five months later. A newer 3.0 snapshot could not be tested because of bug 88221 in newer 3.0 snapshots available at the time of testing.

A warm application startup is defined as starting twice in a row, so the hard disk information is cached in RAM for quick access. On Windows, the Quickstarter feature accomplishes roughly this goal. Above the boxplot shows the upgrade from 1.1.5 to 2.0.0 yielded an impressive 50% gain, cutting warm startup time in half. Also impressive, changes in performance after 2.0.0 are relatively minor for either people or the benchmark to distinguish. The latest stable release version 2.4 weighs among the best scores.

The large gap between warm startup time and cold startup time ranges from 70% to 81% of the total. This implies three-quarters of the cost of starting is bottlenecked at the hard drive, but as an exception to Moore's Law, hard drive performance increases very slowly. If wants to cut cold startup, it must cut hard drive access and not wait for hard drive performance to increase. On the other hand, solid state drives (SSDs), such as those found in the ASUS Eee PC subnotebook, perform better than traditional hard drives and are slowly becoming mainstream.

The performance of opening a document follows a different trend than application startup. From version 1.1.5 to 2.0.0, the opposite happened: the newer version was much slower. The difference was 3.46 seconds (70%) in changes made over 2.5 years.

Cold and warm document open times resemble each other, but the cold times are twice as long. Again, the gap is caused by hard drive performance.

Scrolling is less important performance metric. Nevertheless, the chart's shape is interesting. To my surprise, 3.0 DEV300_m3 breaks the trend and improves performance over version 2.4. I would have expected new features such as notes-in-the-margin feature to slow 3.0 down.

The benchmark exports (or "saves") to the version's native text document format, PDF, and Microsoft Word 97/2000/XP (.doc). The native format for 1.1.5 is .sxw. The native format of versions 2.0 and later is the OpenDocument Format (ODF).

Versions 2.4 and 3.0 show noticeably longer times. In version 2.4, the increase may be the new PDF features. For version 3.0, the increase may be the new OpenDocument Format version 1.2.

Times for closing the document and application are all quick. It's hard to beat a fraction of a second.

The cumulative times (adding up all the individual tests) for each version show a gradual upward trend. For cold start times, version 2.4 is 38% slower than 1.1.5 over a span of 2.5 years.

Similarly for warm start times, version 2.4 is 40% slower than 1.1.5.

In conclusion, is generally getting slower with each release. However, startup performance has made great improvements, the performance losses are relatively small, advances in new computer hardware are more than making up the loses, and continues to mature with new features. doesn't compel users to upgrade, so you are welcome to continue using older versions.

"But my is still slow?

There is no perfect benchmark, and a number of factors influence performance. For example, your machine may benefit from cleanup or from more memory. You may suffering from the rare, specific cases such as a huge number of bookmarks.

Subscribe to the site news feed. In this series of articles, we'll test how to really improve performance.

Related articles


Anonymous said...

To be fair 3.0 is a early beta almost an alpha and with almost 3 months of development left I would say everything is still in the air.

Sam said...

First off! What a FANTASTIC JOB you did! Thanks!

Saying the App is getting slower is definitely not right immho.

We should apply the 80/20 (pareto?) principle ? that making the most critical parts faster, one gets 80% of the real benefit and/or perceived quickness.

My personal take is that getting startup times fast is KEY (and I use OO since waaaaay back then, and on top of OS/2 at that)!! all other tasks where give or take a second, is in final analisys not critical at all - again immho.

Anonymous said...

i switched a couple of years back as part of my general MS boycott. ooo is part of the new lovely free-software universe i came to enjoy.

i have to say that i personally prefer using abiword or even a native text editor for text that ends up in html anyhow.

it seems to me that ooo was construed as an MS-word replacement, and replicates many of its dinosaurish feature-bloat-flaws.

when i find myself having to work on interchangeable documents, i use ooo, and i enjoy the excellent builtin document conversion features to "interoperate" with MS-victims.

ooo wishes to be "fully featured" in the MS-word sense of the word, whereby MS-word has commenced an arms race in the area to survive against the zero-cost competitor.

hopefully the progress towards editable pdf/a and full odf pervasiveness in the market will permit the implementation of lightweight, "low-feature" writing programmes.

Dan Kegel said...

I would like to see this benchmark run with multiple simultaneous users, e.g. simulating a busy LTSP server.

I ran similar (but much simpler) benchmarks a couple years ago on a laptop with a very similar CPU with varying amounts of RAM; results are at
In my tests, cold starting OOo 2.0.2 took at least 11 seconds. This could be the slower laptop drive at work.

Dan Kegel said...

Sorry, the link got truncated; my benchmarks are at

Also, were your benchmarks automated? I'd love to get a copy of the script.

Dan Keegel

Jason Buberel said...

Bless you for including error bars on those charts. Nothing warms the heart more than seeing a scientific approach to this type of analysis.

Keep it up,

Rawler said...

One metric that would be interesting to compare is memory and IO use. Heavy memory/IO use tends to lead to an application that performs well on newer hardware and/or as long as it's more or less running alone, but as soon as you start combining it with some other apps, or running it on older hardware with less ram, you're in for trouble.

Anonymous said...

I'm using OOo 2.4, it comes default with Ubuntu 8.04.

In my opinion, OOo is not slow. Slower then MSOffice? Possibly, but it's not slow and it's no competition going on, really.

What I mean by «not slow», is that it's really fast enough. I can do productive work on it without feeling that I have to sit around waiting for the program all the time.

If it was as the first time I ran WordPerfect 6 (Dos 5.00 and a 3MhZ CPU).
Then it was irritating slow. I had to wait for the words to appear on the screen after I'd written them.

As long as OOo has so many features, as long as I can write without waiting for the text to appear or the calculations to be done, you won't hear me complain. After all if the startup time is five or six seconds to open the first document - even if it ten, it won't matter. Even at work, I can wait ten seconds before I work on a document. If it lags while I'm working or if we're talking 30 - 40 seconds to open a document or do a calculation, then it's too slow!

However, it's nice people does benchmarks like this, so the program doesn't end up too slow.

Nalle Berg

Anonymous said...

Well, this looks a pozitiv result for me. OOo gets slower with new versions, but on the same hardware. If you would merge your results with a chart about advance in hardware speeds, speed would be favorable for OOo. I mean OOo 1.15 probably worked slower on a PC of its time than OOo v3 will work on a PC of our time...

Anonymous said...

well, I don't think this is very good news at all. I use OO.o for "political" reasons: Don't want to use M$ (even if it was available on Linux), and don't like that Abiword are failing to rally behind ODF. But the sluggish behaviour of OO.o does bother me, to say the least. M$ Office is definitely faster and more light-weight than OO! And M$ aren't exactly known for their skill at code optimisation! One of the strong points that Linux can compete with M$ on is the fact that it runs, at better speeds, on older/cheaper hardware. I thus find it a shame that the main office suite is so inefficient and tries to rely on increasing hardware capabilities instead of good coding!

Anonymous said...

Fascinating indeed. Yes, I too would like to see the same tests with multiple users!


Vulcan Eager said...

advances in new computer hardware are more than making up the loses

That's the same excuse MS used to make. See where it has landed them.

Its the same excuse .NET and Java programmers make. How many good word processors do you see developed in .NET and Java?

Aside: I've been asking Linux folks what UI toolkit OO uses but so far I have not received a convincing answer. What toolkit is it?

Anonymous said...

Nice job but...

the memory footprint is often a cause for slowness. Once the machine begins to swap: molasses...

How about some graphs of size against version?

Once again, nice job ..

;) said...

thanks for taking the time to make this.

Cristiano said...

"I've been asking Linux folks what UI toolkit OO uses but so far I have not received a convincing answer. What toolkit is it?"

OO.o implements its _own_ UI toolkit and its own font renderer, and so on. This decision has two consequences:
1) It is easier to implement the exact same behavior in Windows, X11 (Linux, *BSD and so on) and Mac OS, avoiding unexpected changes in our documents when opened in another OS;
2) Makes OO.o the _slowest_ desktop office suite of all times, because it re-implements a lot of stuff that UI toolkits and font rendering systems do.

Cristiano said...

Also, this "re-implement everything" mentality makes certain things harder for the users.

For instance, when you adjust fonts in GNOME (e.g., enabling or disabling anti-aliasing), OO.o happily ignores your system-wide changes. You have to do specifically ajust OO.o too.

Incidentally, Firefox has the same mentality. That's why it is so slow (well, fortunatelly KDE and Apple made webkit) and also ignores your font settings.

NotZed said...

Next time do not break the y axis - it makes interpreting relative values from the plots impossible. It artificially increases differences in some plots. Using 0 would make the plots more useful.

Otherwise, interesting to see the results. If a little disappointing - why does it have to be this way? :(

Anonymous said...

D300m3 is an old build from 14 March. They are up to m14 now. There have been a lot of improvements since that old m3 version used for testing here.

Anonymous said...

You've messed up the Wirth's law. It's states: "Software gets slower faster than hardware gets faster", so Vista is still slower that any of MS-DOS, Win 4 etc. of late 80./early 90. on CPU of that period.

Anonymous said...

I've performed side by side testing on the same machine and OS and on different OSes. Here is what I experienced:

Open Writer. Wait. Wait. Wait. Work.
Open Word 2003. Work.
Open Word 2007. Work.

Open document in Writer. Wait. Wait. Wait. Work.
Open document in Word 2003. Work.
Open document in Word 2007. Work
Open document in WordPerfect 12. Work
Open document in WordPerfect X4. Work.

OpenOffice applications take a seming age to open and then another lengthy period to open even the smallest files. Competing products open very quickly(1-2 seconds for a cold start) and open documents instantly.

I love OpenOffice, almost as much as I like the idea of OpenOffice. But, you're deluded if you think it is anything but slow. Even if it is getting faster than it was, it is still WAY behind competing products, from a performance perspective.

Anonymous said...

a) As applications mature they often do indeed do more work. This does not necessarily mean that they have to get slower. Much of the added functionality does not have to happen at any given time. As long as that functionality is not happening all at the same time. I could write two apps, one that does one function, and one that does that one function and a thousand more, and they could still both be just as fast overall.

Granted, if you are adding more functionality or more complex functionality to an already existing area of functionality - then you can slow down that area. For example, adding spell checking and/or grammar checking to a word processor could quite possibly slow down the display of the words a user types in, or maybe the scrolling of a document. DItto with adding the ability to display images or embedded files in the document. This is why the conditions for benchmarks should be well defined (whether the input file contains images/etc.).

My point is that the "it does more" response should not be used as an excuse for degraded performance as it should be used on a case by case basis, not an overall excuse. Especially since other dependencies (Java for one) now have improved performance.

b) Like many others, I use OOO as a replacement for MS Office. It would be interesting to see a comparison between OOO and MSO for these benchmarks, and for opening MS Office documents (.doc, .xls, etc.) since that is a common usage; a lot of people use OOO to open files created in MSO. This is especially true of people considering using OOO as a replacement for MSO - so if we want people to switch, then we have to do a good job here.

c) While I want my apps to be performant, I will gladly sacrifice some performance (not a lot) to instead get correctness. I have noticed discrepancies between how OOO formats and displays MSO documents than I have noticed the performance. I have also noticed quite a few look and feel problems (I use OOO on OSX).

Combine the performance, the format/display problems and the L&F problems, and OOO seems more like a 1.x version than a 3.x version of an office suite.

That said, I do appreciate the work and the effort made by the developers of OOO.

Anonymous said...

OOo is still dog slow, but the latest release is still far faster for me than 2.4 is/was. Startup time on my machines (Macbook and Macbook Pro with 2GB and 3GB RAM respectively) have about halved.

That brings them _almost_ down to "usable". Quality wise it seems far better too.

I'm still not happy about the startup times, but at least I won't actively avoid starting it anymore.

Anonymous said...

It's good that OOo is finally realize that it's bloated. The first thing to do should be to dump Java and replace it with native only codes.

Bob Gman said...

I'm using OO on all of my computers (one win xp, all the rest - linux). It's more than fast enough. My perception based on many years previous experience with buggy ms products is that it is more stable and more capable. And it's free.

And it's free. And it runs on linux (which is also free and which comes with over ten thousand useful programs, unlike windows which comes with notepad and solitaire).

Anonymous said...

It would be really great to conduct a similar benchmark for Mozilla Firefox, from the Phoenix betas to the latest 3.0-rc. The native format (HTML) didn't change, which would the comparison more fair. The export could be replaced with printing to a file. Changing font size could be an interesting exercise.

Anonymous said...

For the anonymous person complaining about Abiword ODF support: Abiword supports ODF just fine and the ODF filter should normally come with it by default. If you use a distro which doesn't package ODF support with AbiWord, send a bug report to your distro's maintainers.

There's plenty of good reasons why they don't adopt it as their native format. ODF is still largely just a dump of OO.o's internal model; Abi (like just about any other word processor) has different ways of doing many things. If we want to have something which can be the one and only universal default format, that means that all applications have to support all other applications' features. Neither OO.o nor ODF can support some of the things Abi and .abw can do (and the other way 'round).

Anonymous said...

@Jason: Those aren't error bars, it's a box-and-whisker plot.

Anonymous said...

OO need to learn from Firefox and starts a Performance release cycle sooner rather than later.

OO's speed and memory consumption situation can be improved as long as someone cares.

It's about to facing new generation of competition like the google office. If they don't have a great foundation to work on, they will be lagging at the end.

Luckily, after release 3.0, Firefox will be in a nice position when competing against safari and opera.

Anonymous said...

It would be interesting to do the test with the ooo-build patch set (, which is used by default by Novell/SUSE, Red Hat/Fedora, Mandriva, Debian, Ubuntu, etc... They are claiming better performance than the standard Sun version.

Anonymous said...


Fantastic study ... but I wonder how you manage to automate the testing of a gui application like oo ... could you share a little bit about how you did that?

Phil said...

Please redraw all your graphs starting the vertical axis at zero.

And go and read Darrell Huff's "How to Lie with Statistics" and desist from that evil practice which exaggerates differences.

Shame on you!

Anonymous said...

JHC! The past participle of "creep" is "crept".

Anonymous said...

"It would be interesting to do the test with the ooo-build patch set (, which is used by default by Novell/SUSE, Red Hat/Fedora, Mandriva, Debian, Ubuntu, etc... They are claiming better performance than the standard Sun version."

I tried this version... it deos seem a bit snappier, but, it had MAJOR issues - formatting on NATIVE Openoffice documents was fubar'd... tab stops, etc, made perfect templates we've been using for years from version 1.x up to 2.4 broke badly.

I can't believe Novell released such a buggy version.

Andrew Z said...

Anonymous: I plan to test ooo-build and Fedora's soon. By the way, Fedora does not use ooo-build.

Anonymous: I wrote Python software to perform the operations using PyUNO while taking measurements. Then, another Python program manages the first, performs reboots as necessary, and collects reformats the statistics. Finally, R (a statistical program) draws the charts.

Phil: Someone beat you to it. Please read "Responses to 'Is getting faster?'"

Aigars Mahinovs said...

Startup time and document open times are getting into 'ok' category now, but I am very worried about scrolling and saving times. When working of large documents you scroll them and save them much more often than you open them, so any slowdown there is much more detrimental to work performance.

Anonymous said...

From article: doesn't compel users to upgrade, so you are welcome to continue using older versions.

Nonsense. users are pretty much forced to occasionally upgrade for much the same reason users of proprietary office packages are. Support for old binaries on newer OS versions tends to "rot" (especially on Linux and its myriad libraries which does not care too much about 100% backward binary compatibility). File formats change: Most pre- 2.0 versions don't read ODT, and users also want to be able to use the added or improved support for proprietary formats in newer OOo versions. For example, until 2.3.1, OOo could not properly handle the MS docs based on the particular corporate Word template I often have to deal with.

On the plus side, I am mostly a happy OOo user. It does everything I want and in my opinion is easier to use than Word when you want a consistently formatted document. But the resource usage stinks, and does not really seem to get better, if not terribly worse.

Andrew Z said...

Anonymous: Rotting? I had no problems running 1.0.1 through 3.0 on Fedora 7. OOo version 2.4.0 runs on Windows 98SE, while MSO 2003 requires Windows 2000.

Anonymous said...

I had no problems running 1.0.1 through 3.0 on Fedora 7. ...

I'm pleased to hear that. But OOo 1.0.1 was released in 2002, so it's not yet very old software... I recall having DLL trouble installing then-current OOo on a Windows 98 some years ago. Not sure if it was 98SE or the original one, and I don't have that system any more to check.

Anonymous said...

Can you compare with OxygenOffice Professional 2.4 where we use some boost from go-oo builds.

Andrew Z said...

Kami: Yes! In one of the next few.

Anonymous said...

I am used to using Microsoft Office 2007. I downloaded the beta version of OOO 3 last night for windows, and the first thing I noticed was that it is SLOW!

It takes ages to startup, and ages to open and save documents, WHEN COMPARED TO MS OFFICE.

Also, another glaring issue is that the templates don't have a preview function on them.

If these guys want mainstream conversion to their app, they better get these basic issues sorted out.

Anonymous said...

Firs of all I would like to say that this is an excellent article.
As another reader has said, the error bars on the graphs show a scientific approach that raises the credibility of the analysis.

A couple of points about performance comparisons between OOo and MSWord:

(disclaimer: my experience is MSO 2000 vs. OOo 2.0 - 2.2 - 2.4; the comparison in therefore not very fair (an 8-year old product vs. a 0-to-2 years old product), but hey, I don't buy MSO licences just to make performance comparisons)

The startup times of MS Word are shorter than those of OOo Writer; given that both products preload portions of the suite at logon time, I would say that in this area MS Word wins.

When dealing with large documents, i.e. 100+ pages with about 1 image (1-2MB) every other page, file size varying from 70 to 150MB, I have to say OOo wins hands down.
When Word has opened the document, it keeps the CPU a about 100% usage, even if the user doesn't touch the keyboard. Crashes are frequent. Saving is dog slow.
Woriking with a document of the same size and complexity, created from scratch with OOo Writer, is much easier: no crashes, faster saving, lower CPU utilization.

So in my experience OpenOffice Writer handles big documents better that MS Word.

Just my 2 (euro)cents.

Chris said...

Yes, OOO is WAY better with big docs. My partner has suffered writing two genealogy docs-with-lots-of-pictures on MSO2003 and suffered crashes and losses often. The same docs loaded and were editable without issues (except for odd page-numberings across sections). OOO's ToC works, MSO's just crumbles...

Anonymous said...

Hi could you publish the code you used for the benchmark? I'd like to repeat this using squashfs (or reiserfs4) to see if compression could reduce the cold start times.

Andrew Z said...

flyingreptile: Maybe I could run this for you. I was already planning to benchmark Linux filesystems. What exactly would you compress? obviously reads its own files (/opt/openoffice.org3 or similar directory), but it also accesses files all over the disk including /etc, /usr, and /home.

Anonymous said...

Sorry Folks but Wirth's law is incomplete. A more truthful and accurate "Wirth's Law" is as follows:
"Microsoft and Software, hereinafter referred to as M$-Bloatware and OOBloatware, respectively, gets slower faster than hardware gets faster".
Seriously though, it's pathetic to make excuses for badly designed and written code by hiding behind and accepting "Wirth's Law" as a fait-accompli. The fact is that OOo is SLOW and inefficient. Even a layman can reason that if a crappy bureaucratic company like Microsoft (aka Bloatwares-R-Us) can produce an office suite that is much faster than openoffice (with many more features the OOo), then how many excuses are the folks at SUN and OOo going to make before they face up to the fact that their suite is badly in need of a re-architecting? Thanks for your benchmarks, but please stop making excuses for Openoffice and the horrible stagnation that it seems to suffer from.

Unknown said...

Right, let's keep a comment fair, but this should be done in all directions. A program have to be developed, and as a part of this development process it has to be improved in respect to the number and usability of functions - correct.
BUT, although I'm a user of OO since the pre-2.0-time (as OO-dev, to be precise), I have to say: Many functions are available now, but the performance is horrible, not only bad - at least CALC. When I saw some comparisons to MS today (which I don't like, but it is a competitor, of course), I found, that the OO 'eats' at least 5 times more and usually 10 times more CPU power for equal tasks (!!!). Similar bad is the memory usage in such comparisons...

Ok, it might be freeware ... BUT tell me: What do you think, how successful would Firefox be with a comparable performance? It is also freeware, it's memory consumption also was not the best before 3.x (and this is a polite comment, as you might know) - but it's performance always was at least acceptable.

I would say: A program should be developed in ALL directions with equal effort. More functions AND ALSO more performance.
It might be funny to see an enormous increasing number of functions - but the fun dies very soon, if one needs a whole day to do common work, which can be done with other software in the time between get up and breakfast.

Be it freeware or not, a performance difference of 20 to 50% to payware is just acceptable, but NEVER 500-1000% (I can be a fan of OO, but this didn't make my day's last 120-240 hours... time is precious - for everyone)

Unknown said...

Good Work!

I have been a fan of OpenOffice even before it was OpenOffice, back in the days when it was Star Office. I think that everything about it is good, with the sole exception of speed. I would love to see it faster. I think that one of the things that needs to be done is an analysis of how people actually use the programme.

In my case, I tend not to use OO most of the times that I boot up my machine. However perhaps once a week I will run OO and have it open for perhaps 8 hours. On other occasions I may over the course of a few hours open 30 or 40 documents over a short space of time. Most of the times I use OO I don't need to use most of the features that are available - I cannot remember for instance an occasion when I have used mail-merge.

1) On those occasions when I am using OpenOffice for a long period over the course of a day a 30 second start-up time is no problem.

2) When I have to open lots of documents over the course of a day a 30 second start-up time is a problem.

3) On Windows there is a QuickStarter available. However this eats memory (90Mib) so I do not want this running for the 90% of the time that I don't use OO.

Everytime the I use OO I need basic editing abilities such as copying and pasting, and the ability to change fonts and font decorations such as bolding and underlining.

Often When I start OO I need tables, footnotes, spell checking in languages other than English.

Occasionally I need clipart.

Never have I used the Media Player or Mail Merge.

I think that what I would like is the ability to select what features are loaded at switch on time so that only the essential features are loaded into memory, and other features such as mail merge would be loaded just as needed.