brian.lu wrote:
> Hi, experts,
>
> I have a question. When studying firefox startup performance, I found
> that ld.so.1 spent more than 1 second to load some shared library. This
> libraries is loaded by dlopen().
> How can I know what's the most time consuming operation in this loading?
The first thing I'd do would be to isolate the dlopen(). Create a dummy
program:
% cat > main.c
#include <dlfcn.h>
void main()
{
dlopen("slow-app", RTLD_LAZY);
}
And then use LD_DEBUG= to get an idea of what's going on. I've
used RTLD_LAZY here, but you should use whatever firefox is using.
LD_DEBUG=files to see what dependencies are loaded.
LD_DEBUG=symbols,detail to see all symbol lookup
LD_DEBUG=reloc,detail to see all relocations
You can then drill deeper.
The attached dtrace script is one I use to get a general overview.
I'll add or subtract from this to get more info. The output is
something like:
% dtrace -x evaltime=exec -32 -qC -c ./firefox-bin -s ~/dtrace/all.d
Call Counts:
memcpy: 3125
strlen: 3244
malloc: 3333
elf_bndr: 3726
elf_rtbndr: 3726
load_completion: 3830
elf_reloc_relative: 10566
elf_hash: 20062
strcmp: 86359
elf_find_sym: 381467
Raw Times (msecs):
load_completion: 742774
call_init: 747819
file_open: 970683
elf_reloc: 1214110
relocate_so: 1214372
load_so: 1278085
load_one: 1286340
load_path: 1287142
elf_find_sym: 1338652
relocate_lmc: 1581881
relocate_lmc() is the main relocation engine, which
spends most of its time looking up symbols (elf_find_sym()).
Note the "call_init" too. This is where ld.so.1 calls the
.init sections of any loaded objects. I've seem dlopen()
objects that do huge amounts of .init processing - this
all occurs before return from the dlopen(). .init's have
been known to dlopen() other objects, start threads, and
even fork/exec programs :-)
I'm sure a much better DTrace script could be written.
Which object are you observing that takes so long to dlopen()?
--
Rod
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: all.d
URL:
<http://mail.opensolaris.org/pipermail/tools-linking/attachments/20051124/f08865ca/attachment.ksh>