On Mon, 21 Jan 2008 16:18:35 +0000 Andy Green <[EMAIL PROTECTED]> babbled:
> > Two interesting approaches to "fix" this would be: > > > > a) Ditch X and write a nice and fast, framebuffer-based SmartPhone > > application controller. [yes, accelleration may be a problem here] > > Something tells me Carsten will not like to ditch X ;-) > > If I understood his point, he is saying that everywhere he looks he sees > bloat, and that he can imagine to put some of these apps on a serious > diet and / or move them out of X init to bite into that 15s he sees > going that way. And indeed a settings-*daemon* doesn't need pango, etc. 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. 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. rememebr too - every x process that starts has to connect to x (that's a round trip just for that and then at least several more as xlib discovers things about the display and keeps locally). gdk/gtk then add even more queries on top. if you have several processes all hammering the cpu to connect to x on startup it will introduce latency to the startup as everyone contends for context switches to the same source. minimising what you start up would help. rolling multiple things into 1 process will help. in the long term we should dig deep into everything involved in bootup and see what we can do. one other problem we have is... app startup - runtime. you press a button in the launcher and have to wait... wait... wait. dialler takes 4 seconds. as does the phonebook. there are 2 things here to address 1. generic startup times for all processes/apps - what can we do to speed things up? any ld.so tricks we can play? for gtk apps can we make use of copy-on-write tricks the maemo guys did with maemo-launcher (it's pure evil. they literally have a process pre-spawned that has done PARTs of the gtk init - everything that invovles reading config files, font info off disk etc. but not the x connection. then they basically message that and fork then dlopen() the final process and jump to main - i think they actually jump to a special maemo main call as this will exist if the process knows about quick startup and this main loop will skip the init he parent already did). with copy on write this means most of the data read and parsed here will never change - it just is read later. it's evil - but works. 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 > Sounds good! > > - -Andy > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iD8DBQFHlMXbOjLpvpq7dMoRAgV+AJ98ERA8VofHzbnY7uSjzo0t0Y1drgCfQtJm > gaHkJ1XpN/q13h69rkSMpG4= > =6tI1 > -----END PGP SIGNATURE----- -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
