On Tue, 2008-01-22 at 13:19 +1100, Carsten Haitzler wrote: > On Tue, 22 Jan 2008 00:26:39 +0000 Richard Purdie <[EMAIL PROTECTED]> babbled: > > 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).
If the build system is working properly, it should find it first time. If its not, the rpath magic is wrong. > > 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. In a handheld arm C based system like Poky, I see a measurable difference in device boot time and application startup time.... > > > 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? My experiences suggest otherwise. Poky has a prelink .bb recipe and I've just synced it into OE so it has the eabi fixes too if anyone wants to experiment. Cheers, Richard
