[Dev] Tizen 3.0 : Optimizing applications launch time

Patrick Ohly patrick.ohly at intel.com
Tue Oct 22 08:39:13 GMT 2013


On Tue, 2013-10-22 at 10:35 +0300, Ylinen, Mikko wrote:
> Hi Stephane,
> 
> On Mon, Oct 21, 2013 at 5:56 PM, Stéphane Desneux
> <stephane.desneux at eurogiciel.fr> wrote:
>         I saw in the launchpad code that the preloading uses dlopen()
>         with the flag RTLD_NOW: this forces to load all unresolved
>         symbols, thus the whole library tree.
>         
>         
>         As the WRT launchpad executes this dlopen() for all binaries
>         listed in /usr/share/aul/preload*.txt, this leads to loading
>         nearly 200 libs:
>         # for x in $( cat /usr/share/aul/preload*.txt); do ldd $x;
>         done | awk '{print $1}' | sort | uniq | wc -l
>         202
>         
>         This is confirmed by reading the list of mapped files for the
>         process:
>         # readlink /proc/$(pgrep wrt_launchpad)/map_files/* | grep .so
>         | sort | uniq | wc -l
>         205
> 
> 
> Just out of curiosity: will the WRT launchpad daemon startup time
> improve if you disable libs dlopen()?
> 
> 
> This is important for the system startup time.

Perhaps also worth investigating: is RTLD_NOW necessary or can RTLD_LAZY
be used?

Stéphane said that it causes loading "the while library tree", which is
a bit misleading. The same set of libraries should be loaded with and
without it. The difference is that symbol resolution happens for
everything during loading when RTLD_NOW is used, while it gets deferred
for functions until they are actually used with RTLD_LAZY.

Symbol resolution can be expensive, so startup time might benefit from
not doing it immediately. Functions that never get called don't need to
be resolved at all.

On the other hand, because functions get called in the forked processes,
this work then needs to be done over and over again, which negates the
purpose of preloading somewhat.

There may be a way to get the best of both worlds: during startup, use
RTLD_LAZY. Then sometime later, call dlopen() again for the same modules
with RTLD_NOW. According to the dlopen() man page, that has the effect
of retroactively resolving all symbols without actually loading the
module again.

Something else to watch our for is that switching between
RTLD_LAZY/RTLD_NOW may also affect which symbols a function call is
bound to. This is probably unlikely, but who knows...

Another semantic difference is that a module fails to load with RTLD_NOW
if any of its symbols cannot be resolved. With RTLD_LAZY, it gets loaded
and a runtime error occurs when calling an unresolvable method.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.




More information about the Dev mailing list