On Wed, 9 Jul 2008 22:31:45 +1000 Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]> babbled:
> what i need to do is find out why it takes 6 seconds to init and have the > socket up and working. there's a lot of paging going on there. i wonder if > its the paging in of shared libs mostly, or something more insidious... and... i did some examining... yup. 4.2 seconds alone of the 6 is ld.so JUST loading in shared libs! eeek! geeez! then about another 1.5 seconds is actual init code (setting up signal handlers, looking for existing loadable modules as evas for example dlopen()'s loaders, savers and engines on-demand as needed) and of that i think about 0.2 seconds is looking at theme files that define the look, and then pretty much loading and decoding data for images and fonts... so thats the 6 second lag. almost exclusively loading shared libs, resolving symbols. so as suspected... we are definitely fs/io limited here as his should be a LOT faster (on a desktop with a normal hdd even when nothing is cached this process is normally well into the sub-second range). so the question now is.. what to do about it. theres definitely a lot of libs getting sucked in - thats due to exquisite building on efl and efl by default linking ot and using xlib and a tonne of other libs... i can try do a special build of exquisite that: 0. build a special subset of efl libs with ONLY fb engine and just the minimum enabled for exquisite to work 1. statically builds in efl libs into exquisite 2. make sure these efl libs have their own prefix so the loadable modules are loaded from this prefix only... it might help... how much... will need me to get all this done and then measured. -- Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>
