Hi, On Tue, Oct 22, 2013 at 3:52 PM, Patrick Ohly <[email protected]>wrote:
> On Tue, 2013-10-22 at 10:01 +0000, YOUNG IK CHO wrote: > > > 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. > > > > > > That's the reason why launchpad use RTLD_NOW instead of RTLD_LAZY. > > symbol loading is performed on the launchpad/wrt_launchpad startup. > > Launchpad or wrt_launchpad may be delayed due to symbol resolution but > > once symbols are resolved, child process of launchpad, all the apps, > > can benefit from pre-initialized shared library as long as it does not > > clear memory space by execve(). > > Agreed. I already came to the same conclusion. > > So what do you think about my idea of delaying (not removing!) the > symbol resolution? Has that perhaps also been considered before? Of > course that only makes sense if there is some benefit for startup time. > I'd like to resume this thread. I think Patrick's idea is worth investigating but I'd like to get feedback from the launchpad authors first. Has any of this been studied earlier? I wrote a simple dlopen benchmark tool that measures the time spent in dlopen()'ing the preload_list* files. Especially preload_list_wrt.txt takes considerably long during boot. And this is almost everything wrt_launchpad_daemon does during init. -- Mikko
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
