On Tue, 22 Jan 2008 00:26:39 +0000 Richard Purdie <[EMAIL PROTECTED]> babbled:
> 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. oh - i know. almost every lib i know has a fair number of writable sections - also the mmap setup does take time as does the search for the lib (statting multiple dirs for the lib). > 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. yeah. this might help. with C though i have yet to find any real measurable difference. c++ though seems to have a massive gain. > > 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? no - but you may access different parts of the libs - so having to page in those sections will cost something. > > 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. yup. i know. but - if you are not talking c++ i am not sure we will get an appreciable gain? -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
