userland boot time

[Richard Purdie]

On Tue, 2008-01-22 at 10:11 +1100, Carsten Haitzler wrote:
> indeed. in fact it ONLY needs gtk/gdk/glib/pango/ etc. for 1 thing - listening
> for gconf changes and then modifying x properties. the only thing it needs
> there is its socket to gconf to get the message - that's a lot of library to 1.
> load off disk, page in and decompress, 2. resolve symbols etc. to then not use.
> 3. call gdk_init() whihc does a fair bit mroe than just connect to x. remember
> we do a lot of init there that doesn't need to be done for this process.

You also need to keep in mind the games the kernel plays on your behalf
with dynamic libraries. Each app does not have its own copy of the
library, these are loaded once and them mmaped read only into each
process apart from the writable sections which are marked for copy on
write.

I know OM doesn't use it atm but a lot of the linking overhead can be
reduced with prelink in two ways. Firstly by analysing the whole system,
each library can be given a unique load address avoiding any need to
relocate anything. Secondly, the prelinked tables can be checked for
validity and used instead of the normal linking process.

> andy is right - i am just digging deep into some example apps i suspect of
> extra-happy-fun-time bloat that will be slowing down our startup. every MB of
> disk data we need to load for code, libs or whatever is an MB of data to
> decompress and given our read speed from flash are in the 2-3MB/sec range on a
> good day (hell - i was seeing 190KB/sec), thats a LOT of cpu and IO lag/time we
> spend. trim where it can be trimmed.

Assuming it does this for each library each time its accessed. Does it?

> 2. some apps (or features) we want to keep around at the touch of a button.
> dialler, sms read/send, phonebook etc. as they are currently separate processes
> they should be run in the background but kept hidden until needed - simply dont
> show a window. maybe in the long run such core things you always want around
> could/should be considered as dlopen() candidates as modules so they cleanly
> share the same init code in 1 process, but each simply extends with a new
> ui/usability component. in general this is bad as instability in one affects
> the others (as long as the process restarts itself in the event of a crash we
> should have minimal impact). as i said - only some things you want to have
> instantly on-tap at all times should do this. others should stick to the
> process model per app

Also keep in mind if you start dlopen'ing things prelink can no longer
help you and dlopen() hits the linker just the same as linking when you
execute something normally.

Cheers,

Richard