OOo *really* slow startup time

[JonElsas]

Hello - I haven't seen this problem mentioned in the board, but it may be there. (the search doesn't seem to be working...)

System config:
--OSX 10.2.6
--900MHz 12" iBook
--640 M of memory
--Apple's X11 Beta 3 - default installation
--OOo 1.0.3 - default installation

When I attempt to start OOo, either by the Start OpenOffice.org.app or by executing 'soffice' from the command line w/ the X server running, it takes several *minutes* (10-20) to even display the splash screen. It seems to take longer & longer each time I start the app.

I've tried re-naming libGL.dylib, but that had no effect. I am not doing anything out of the ordinary w/ system fonts - that's all out-of-the-box OSX. I saw an error about /usr/bin/lpc not being found by the Start script, and I sym-linked /usr/bin/lpc to /usr/sbin/lpc, but it had no effect.

any help is REALLY appreciated. I WANT to use OOo, but the startup time is really making me consider other word processors

thanks in advance,
Jon

[JonElsas]

the CPU is around 100% utilization during the entire startup time (10-20+ minutes)

[OPENSTEP]

That's a new one on me too. I've seen it take long, but I thougt those speeds were never reachable You have 600 megs of physical memory...how much free space do you have on your hard drive? You should probably have at least 1 gig free for swap/virtual memory. If your drive is incredibly fragmented and you don't have much, the virtual memory system may just be thrashing the hard drive.

Well, there are two options for this. One, if you're a hacker, is to try to get the ooqstart project running. I believe Scott Dietrich (or was it a different scott?) had it working on OS X. That wouldn't address the length of startup time, but at least it might amortize it.

The other one is to try and help track down what's causing the long startup times. Basic procedure:

1) Install Apple Developer Tools if not on the box.
2) Open one terminal, proceed to start OOo from a command line.
3) While it is "hung", open a new terminal
4) top -u
5) Check to see that it is soffice.bin near the top pegging the CPU and not X11.app. Make a note of the pid of soffice.bin. Should be the leftmost column.
6) gdb -p pid_from_step_5
7) Wait for gdb to fully start (you'll get lots of "loading sharded libraries" dots...yup, it's big, and if you're having virtual memory problems like mentioned at first, this may not even work since it can take over a Gig of memory)
8 ) thread 1
9) bt
10) thread 2
11) bt
13) Repeat step 10 & 11 with increasing numbers until you get a "Thread ID not known" error message
14) post results here

Anyone out there a gdb expert that can perhaps make the process from 6 to 14 (getting full stack traces of an attached process) simpler?

ed

[OPENSTEP]

Oh yeah, for others who may drop in and read...

10-20 minutes is abnormal.

1-2 minutes is expected.

This won't be addressed until 1.1, and it's not a Mac problem...it's present on all platforms where OOo 1.0 runs, including Win32.

One way to address it is to get a G5 where OOo/Neo/NeoJ are fast as sin But for those of us with limited budgets...

This girl is a heavyweight, and you may need to adapt the way you use your office suite to work around this. The easiest way is to never close all of the open document windows. Unlike a Mac application that remains running when you close all of its windows, OpenOffice.org is more like a win32 program and will quit if there are no documents open. This blows hole when combined with the 1-2 minute start time.

Tip 1 : After OOo starts the first time, create a new blank word processing document. Minimize it down into the dock. Always leave it open. This will keep the program loaded.

Tip 2 : Make "Start OpenOffice.org" one of your Login items (System Preferences > View > Login Items > Add...). This will start X11/XDarwin when you login as well as OOo. Once the first window opens, Tip 1. If you use OOo frequently, this will help make it handily available.

Tip 3 : If you're about to close a window and don't see that minimized empty word procssing document in the Dock, before you close it make a new empty word processing document and minimize it.

Since I haven't had the time to get ooqstart running, I've just trained myself to do the above. It basically mimics what ooqstart does under the hood...keeps parts of the program continually running and running on startup to minimize startup time. I believe the stupid little butterfly in the toolbar on Win32 that's distributed with OOo/StarOffice does the same thing since it sucks away 17 megs of memory on my NT test box (yes, I have one...gotta compare OOo with something that works somewhere) which seems a bit over the top for a stupid butterfly with a menu.

ed

[JonElsas]

thanks for the prompt reply & tips. I've been trying to keep an OO window open, but I might give ooqstart a shot.

I'm pretty sure I've got plenty of swap space available & the hard disk is about 60% full (its a 40 gig disk)

after my last posting, just for kicks, I started the spadmin tool. This crashed fairly quickly & looking at the crash log, I saw:

[OPENSTEP]

Please let me know what your experimentation brings, if you continue onwards. I hadn't quite expected this large of an issue with some fonts when we put together our final installer. If we can come up with a list, though, I can make sure to explicitly exclude those fonts from the final installer.

The other interesting thing to note is that to use all the fonts, it does load all of them into memory when it starts up...and this can take up quite a bit if there ar emany fonts.

If you're adding in the fonts one at a time, or adding new fonts, you can use Start OpenOffice.org to do your font conversion from a Mac font to TTF by dropping the mac font over Start OOo. Each time you add a new font, you'll have to do that pspfontcache removal. I think if you don't the font may show up in menus, but the font itself doesn't get displayed.

oh man, if anyone does know of truss replacement...<grin>

ed

[Terry Teague]

[darkith]

I was having this problem, excrutiating startup times, all of a sudden.

Based on these posts, I tinkered with the font directory, and narrowed it down to two fonts. Hope the non-ascii characters survive to some degree...

These fonts show up like this in a terminal:
-rw-r--r-- 1 darkith wheel 13510112 Jul 28 21:50 ????????????.ttf
-rw-r--r-- 1 darkith wheel 13540644 Jul 28 21:51 ????????????.ttf
like this in "cat fonts.dir": (starts with bunch of asian characters, might not display)
????.ttf -misc-åæç»é»-normal-r-normal-utf8-0-0-0-0-p-0-iso10646-1
????.ttf -misc-åæé»ä½-normal-r-normal-utf8-0-0-0-0-p-0-iso10646-1
and like this in "vi fonts.dir":
\xe5\x8d\x8e\xe6\x96\x87\xe7\xbb\x86\xe9\xbb\x91.ttf -misc-\xc3\xa5\xc2\x8d\xc2\x8e\xc3\xa6\xc2\x96\xc2\x87\xc3\xa7\xc2\xbb\xc2\x86\x
c3\xa9\xc2\xbb\xc2\x91-normal-r-normal-utf8-0-0-0-0-p-0-iso10646-1
\xe5\x8d\x8e\xe6\x96\x87\xe9\xbb\x91\xe4\xbd\x93.ttf -misc-\xc3\xa5\xc2\x8d\xc2\x8e\xc3\xa6\xc2\x96\xc2\x87\xc3\xa9\xc2\xbb\xc2\x91\x
c3\xa4\xc2\xbd\xc2\x93-normal-r-normal-utf8-0-0-0-0-p-0-iso10646-1

Removing those two fonts (or rather mv'ing the truetype directory, creating a new truetype dir and mv'ing everything else into it), and deleting those two fonts from "fonts.dir" improved my 10-20 minutes startup time to 30-35 seconds (splash screen in 10s). Powerbook G3/300, 320 MB.

HTH.
Darkith

[OPENSTEP]

I suspect those to be the Asian fonts. I notice that even in my regular US English installs, I still have Asian fonts in my system fonts folder. For what it's worth, they appear to be four to five times the size of the Western fonts...and if Freetype is trying to parse them I could see how that could really draw out the startup time. Not to mention we can't use them in OOo properly anyway since OOo doesn't understand the Mac Asian font encodings yet

I suspect for our next release it'd be good to come up with a list of "excluded" fonts for the import stage, particularly if they're having such a drastic impact on the startup time.

ed

[Max_Barel]