maemo.org - Talk - [Debian] preloading openoffice to speed up starting

maemo.org - Talk (https://talk.maemo.org/index.php)

- Alternatives (https://talk.maemo.org/forumdisplay.php?f=36)

- - [Debian] preloading openoffice to speed up starting (https://talk.maemo.org/showthread.php?t=22353)

debernardis

2008-07-28 11:52

[Debian] preloading openoffice to speed up starting

For those who happen to use openoffice.org on the NIT, there's a simple command to shorten its startup time.

The command

Code:

debbie ooffice -nologo -nodefault

preloads parts of openoffice - it will steal you one or two second for its execution and some 23 megs memory.

From my experiments on my freshly booted 810, starting "ooffice" without this preload needs about 30 seconds, which scale down to 15 seconds after the preload.

I still have to fiddle with the booting scripts to determine the best way of autostarting the thing.

qole	2008-07-29 06:18

Re: preloading openoffice to speed up starting

I think it would be nice to bundle some if not all of your speedup tips into a future version of the easy chroot; I've just bundled the /tmp resize trick and it has done wonders; suddenly I can open complex documents in OpenOffice (before, it would just silently drop pictures, etc), print to PDF, print via CUPS properly, etc, etc...

Could you re-post your other OpenOffice optimizations here?

debernardis

2008-07-29 07:40

Re: preloading openoffice to speed up starting

OK :-)

Here are some reposts - other goodies will be posted here when available. Though I don't think you will be able to default the chroot to these, unless you hardcode the openoffice preferences which go into the /home/user personal space.

Another trick to shorten openoffice.org startup. Fire up an openoffice instance (ex. writer), go to tools / options, then in the list look for openoffice.org and memory. Change "use for openoffice.org" to 30MB and "memory per object" to 2MB. Seems to work in my hands albeit I did no measures (placebo is enough for me :-).
Taken from http://www.linuxformat.co.uk/pdfs/do...feat_speed.pdf which is a very interesting source of speeding advices.

This is to be able to open openoffice documents from the file manager.
dbus-switchboard allowed me to associate .odt files with openoffice writer.
In defaults.list put "application/octet-stream=hildon-dbus-switchboard.desktop" as stated by pipeline for files unknown by hildon.
In .dbus-switch-apps.cfg add

Code:

Oowriter,cli,debbie oowriter "%params%"

(double quotes were needed in my hands to allow filenames containing spaces).
In .dbus-switch-xref.cfg add

Code:

.odt,Oowriter,

This was enough. Other ooo file types work similarly.

Managing the "restoring files" window in openoffice.org
This particular window, when shows, is too high for the 800x480 NIT screen and its buttons lay behind the visible area - plus, there's no way to move the damn'd modal window and to push the OK or CANCEL buttons, except that tabbing and hitting return in a blind way. Luckily, there is a cure.
In Openoffice tools/options menu, go find the "view" screen and on top you'll find a field which controls the scaling of the user interface widgets. Scale down it to 80% (or experiment with other values) and you'll see the restoring files window is going to enter comfortably into your screen - plus, all the toolbar icons will be visible.

qole	2008-09-10 22:55

Re: preloading openoffice to speed up starting

I stumbled across this in the /usr/bin/startlxde file. I ran OpenOffice under LXDE but couldn't see any difference, however. Any ideas?

Code:

# Enable GTK+2 integration for OpenOffice.org, if available.

export SAL_USE_VCLPLUGIN=gtk

EDIT: More info here. I wonder if we should go a step further and force desktop detection to "Gnome" by using OOO_FORCE_DESKTOP="gnome"

EDIT2: That page suggests a couple of variables that might speed things up a bit...

Quote:

SAL_DISABLE_SYNCHRONOUS_PRINTER_DETECTION
If set to nonempty value disables synchronous printer detection. This can help on startup e.g. if your CUPS server is very slow.

SAL_NOOPENGL
Disables usage of OpenGL if set to "true".

qole	2008-10-07 23:01

Re: preloading openoffice to speed up starting

I'm curious about this; I'd like to see some results.

If you're willing to (perhaps) drain your battery a bit more in order to get more performance out of OpenOffice, you might gain some speed by setting your processor to "performance" mode. lcuk does this with his liqbase, it might really help OpenOffice, too.

Make two little scripts, one called "cpu-perform" and one called "cpu-ondemand" (or whatever you want) and then run them as root (eg, sudo cpu-perform)

cpu-perform

Code:

echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

cpu-ondemand

Code:

echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

(don't forget to chmod +x cpu-perform)

debernardis

2008-10-08 04:55

Re: preloading openoffice to speed up starting

Wow! This seems to work, definitely, just at the first test! Makes OOO much more usable. Now I wonder how much battery-time I lose by having this on while I use my tablet (and off when it's in my pocket).

qole	2008-10-08 05:51

Re: preloading openoffice to speed up starting

Great, I'll add these scripts to Easy Debian.

debernardis

2008-10-08 07:22

Re: preloading openoffice to speed up starting

If I were able, I'd modify the slidelock package (which I always use on my n810 - and also on my n800 after pushing the secret button which makes its secret sliding keyboard slide out) :cool: to set performance when the slide is open, and ondemand when it's closed. I'm going to ask Jgallen23 (the developer) to include this in his next version.

EDIT: I was able indeed. It's just a minor modification in /usr/lib/SlideLock/SlideLock.py. The modified version is as follows:

Code:

#!/usr/bin/env python

import dbus,gobject,time,os

from dbus.mainloop.glib import DBusGMainLoop





def main():

        slidestatus = '/sys/devices/platform/gpio-switch/slide/state'



        DBusGMainLoop(set_as_default=True)



        bus = dbus.SystemBus()



        tklock = bus.get_object('com.nokia.mce','/com/nokia/mce/request')



        def msg(id,obj):

                f = open(slidestatus,'r')

                status = f.read()

                f.close()

                if status == "closed\n":

                        tklock.req_tklock_mode_change(dbus.String("locked"))

                        os.system("echo ondemand >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor")



                if status == "open\n":

                        os.system("echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor")



        bus.add_signal_receiver(msg,dbus_interface="org.freedesktop.Hal.Device",signal_name="PropertyModified",path='/org/freedesktop/Hal/devices/platform_slide')

        loop = gobject.MainLoop()

        loop.run()



if __name__ == "__main__":

        main()

Now let's see how many Coulombs does it burn :p

qole	2008-10-08 16:32

Re: preloading openoffice to speed up starting

(qole looks all over his N800 for anything that could be called a "slide", doesn't find anything, shrugs, and goes back to his virtual keyboard)

qwerty12

2008-10-08 16:36

Re: preloading openoffice to speed up starting

The external memory card slides out :P

qole	2008-10-08 16:43

Re: preloading openoffice to speed up starting

The judges are debating... it seems qwerty12's response is quite controversial... The Russian judge is shaking his head... The German judge is waving her hands... The Lithuanian judge is pulling the memory card out of her N800 and putting it back in, and the American and British judges are looking at their N800s, squinting and turning their heads sideways...

After a last burst of whispered debate, it seems the judges have come to an agreement... Yes, qwerty12's comment was fair! The point goes to qwerty12!

debernardis

2008-10-08 17:38

Re: preloading openoffice to speed up starting

Now why not: a daemon which polls the list of running processes and sets performance governor when openoffice and/or a list of other stuff are active, or ondemand when no program from list is running.
Wish I were literate enough to start coding :-)

qole	2008-10-08 17:40

Re: preloading openoffice to speed up starting

Quote:

Originally Posted by debernardis (Post 231729)

Great idea; like you, I am a hacker, not a coder...

debernardis

2008-10-31 07:46

Re: preloading openoffice to speed up starting

Qole, your /sbin/cpu-perform script ends with

Code:

echo '' >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

Is it a bug or there is a reason for those quotes?

qole	2008-10-31 15:24

Re: preloading openoffice to speed up starting

My thought was that scaling_governor = "null" was supposed to "lock-in" the last CPU setting.[1][2]

But it looks like '' does not equal 'null', and it is ignored anyway. If you "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor" after running the script, it is set to "performance". I'll try with the next version of the Easy Debian scripts to get that one right; it should probably be 'null' instead of ' '.

lcuk	2008-10-31 16:14

Re: preloading openoffice to speed up starting

please make that auto slide lock cputweak thing an OPTION.
I run in performance all the time and slide my keyboard in and out very often.

I might want it locked when closed up, but I might (and usually am) using the device to build and compile and there is a VERY significant difference in build times ondemand vs performance.

its for this exact reason that I never released acmonitor with a very similar patch included: on charge==performance, on battery=powersave

As for battery duration, remember that on the default "ondemand" the cpu still fires upto maximum speed when required anyway, "performance" simply saves the ramping up difference, when tasks need the speed its there.

I don't run out of battery even staying at performance, but I dont leave my cpu pegged all the time.

I only ever run out of battery when my wifi is left on, and the cpu settings dont touch that.

All times are GMT. The time now is 13:20.

vBulletin® Version 3.8.8